On Sat, Aug 31, 2019 at 04:44:48PM +0200, Christoph Hellwig wrote:
> On Sat, Aug 31, 2019 at 02:35:37PM +0100, Al Viro wrote:
> > > So for the one real life example of the configfs attribute life
> > > actually is simpler. acpi_table_aml_write verifies early on that
> >
On Sat, Aug 31, 2019 at 10:32:41AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 26, 2019 at 08:28:19PM +0100, Al Viro wrote:
> > For configfs bin_attr it won't work, simply because it wants the entire
> > thing to be present - callback parses the data. For SCSI tape... M
On Fri, Aug 30, 2019 at 02:10:42PM +1000, Dave Chinner wrote:
> > reiserfs_file_release():
> > tries to return an error if it can't free preallocated blocks.
> >
> > xfs_release():
> > similar to the previous case.
>
> Not quite right. XFS only returns an error if there is data
> writeba
On Thu, Aug 29, 2019 at 11:22:58PM +0100, Al Viro wrote:
> On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote:
>
> > Most of them are actually pure bollocks - "it can never happen, but if it
> > does,
> > let's return -EWHATEVER to feel better". S
On Tue, Aug 27, 2019 at 06:27:35PM +0100, Al Viro wrote:
> Most of them are actually pure bollocks - "it can never happen, but if it
> does,
> let's return -EWHATEVER to feel better". Some are crap like -EINTR, which is
> also bollocks - for one thing, process
On Tue, Aug 27, 2019 at 06:01:27PM +0300, Boaz Harrosh wrote:
> On 26/08/2019 22:32, Al Viro wrote:
> <>
> > D'oh... OK, that settles it; exclusion with st_write() would've been
> > painful, but playing with the next st_write() on the same struct file
> &g
On Tue, Aug 27, 2019 at 02:21:50PM +0200, Miklos Szeredi wrote:
> On Tue, Aug 27, 2019 at 1:58 PM Al Viro wrote:
> >
> > On Tue, Aug 27, 2019 at 10:51:44AM +0200, Miklos Szeredi wrote:
> >
> > > How about something like this:
> > >
> > > #if BIT
On Tue, Aug 27, 2019 at 10:51:44AM +0200, Miklos Szeredi wrote:
> How about something like this:
>
> #if BITS_PER_LONG == 32
> #define F_COUNT_SHORTTERM ((1UL << 24) + 1)
> #else
> #define F_COUNT_SHORTTERM ((1UL << 48) + 1)
> #endif
>
> static inline void get_file_shortterm(struct file *f)
> {
On Mon, Aug 26, 2019 at 09:34:37PM +0300, "Kai Mäkisara (Kolumbus)" wrote:
>
>
> > On 26 Aug 2019, at 19.29, Al Viro wrote:
> >
> > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> >
> >>We might be able to paper over that mes
On Mon, Aug 26, 2019 at 11:20:17AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 26, 2019 at 05:29:49PM +0100, Al Viro wrote:
> > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> >
> > > We might be able to paper over that mess by doing what /dev/st does -
> &
On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote:
> We might be able to paper over that mess by doing what /dev/st does -
> checking that file_count(file) == 1 in ->flush() instance and doing commit
> there in such case. It's not entirely reliable, though, and it&#
On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr
On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> If I understand your patch description well, using compat_ptr_ioctl
> only works if the driver is not for s390, right?
No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
and be done with that; compat_ptr
On Tue, Apr 16, 2019 at 10:19:48PM +0200, Arnd Bergmann wrote:
> A handful of drivers all have a trivial wrapper around their ioctl
> handler, but don't call the compat_ptr() conversion function at the
> moment. In practice this does not matter, since none of them are used
> on the s390 architectur
On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> Acked-by: Darren Hart (VMware)
>
> As for a longer term solution, would it be possible to init fops in such
> a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
> so we don't have to duplicate this boilerplate
On Wed, May 16, 2018 at 11:43:04AM +0200, Christoph Hellwig wrote:
> We currently have hundreds of proc files that implement plain, read-only
> seq_file based interfaces. This series consolidates them using new
> procfs helpers that take the seq_operations or simple show callback
> directly.
>
>
On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote:
> +++ b/fs/proc/internal.h
> @@ -48,8 +48,8 @@ struct proc_dir_entry {
> const struct seq_operations *seq_ops;
> int (*single_show)(struct seq_file *, void *);
> };
> - unsigned int state_size;
>
Suppose vhost_scsi_iov_to_sgl() got a two-iovec array, mapped
e.g. 20 pages from the first one just fine and failed on the
second.
static int
vhost_scsi_iov_to_sgl(struct vhost_scsi_cmd *cmd, bool write,
struct iov_iter *iter,
struct scatterlist *sg, int
On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
> Since right after the user copy, we are going to
> memset(&karg, 0, sizeof(karg)), I guess an access_ok check is enough?
access_ok() is *NOT* "will copy_from_user() succeed?" Not even close.
On a bunch of architectures (sparc64, for one)
On Thu, Apr 20, 2017 at 07:54:45PM +0200, Arnd Bergmann wrote:
> kernelci.org reports a new compile warning for old code in the pmcraid
> driver:
>
> arch/mips/include/asm/uaccess.h:138:21: warning: passing argument 1 of
> '__access_ok' makes pointer from integer without a cast [-Wint-conversion]
o /dev/sg shouldn't be equivalent to the ability to trigger
BUG_ON() while holding spinlocks...
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro
---
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index dbe5b4b95df0..121de0aaa6ad 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1
On Mon, Dec 05, 2016 at 04:17:53PM +0100, Johannes Thumshirn wrote:
> 633 hp = &srp->header;
> [...]
> 646 hp->dxferp = (char __user *)buf + cmd_size;
> So the memory for hp->dxferp comes from:
> 633 hp = &srp->header;
> >From my debug instrumentation I see t
On Tue, Feb 03, 2015 at 06:29:59AM +, Nicholas A. Bellinger wrote:
> + * Copy over the virtio-scsi request header, which when
> + * ANY_LAYOUT is enabled may span multiple iovecs, or a
> + * single iovec may contain both the header + outgoing
> +
On Mon, Feb 02, 2015 at 04:44:12AM +, Al Viro wrote:
> On Mon, Feb 02, 2015 at 04:06:24AM +, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger
> >
> > This patch adds a new memcpy_fromiovec_out() library function which modifies
> > the passed *iov
On Mon, Feb 02, 2015 at 04:06:24AM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> This patch adds a new memcpy_fromiovec_out() library function which modifies
> the passed *iov following memcpy_fromiovec(), but also returns the next
> current
> iovec pointer via **iov_out.
>
On Sun, Jun 22, 2014 at 07:50:07AM -0400, Theodore Ts'o wrote:
> On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
> >
> > PS: I agree that it's worth careful commenting, obviously, but
> > before sending it to Linus (*with* comments) I want to get a
>
On Sun, Jun 22, 2014 at 01:53:52AM +0100, Al Viro wrote:
> On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
> > > No, we are not. Look:
> > > * comparison promotes both operands to u64 here, so its result is
> > > accurate, no matter how large c
On Sat, Jun 21, 2014 at 05:32:44PM -0700, James Bottomley wrote:
> > No, we are not. Look:
> > * comparison promotes both operands to u64 here, so its result is
> > accurate, no matter how large count is. They are compared as natural
> > numbers.
>
> True ... figured this out 10 seconds afte
On Sat, Jun 21, 2014 at 05:03:20PM -0700, James Bottomley wrote:
> > Anyway, does the following alone fix the problem you are seeing?
> >
> > diff --git a/include/linux/uio.h b/include/linux/uio.h
> > index ddfdb53..dbb02d4 100644
> > --- a/include/linux/uio.h
> > +++ b/include/linux/uio.h
> > @@
On Sat, Jun 21, 2014 at 07:09:22PM -0400, Theodore Ts'o wrote:
> On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
> >
> > ed include/linux/uio.h < > /iov_iter_truncate/s/size_t/u64/
> > w
> > q
> > EOF
> >
> > Could you check if t
On Fri, Jun 20, 2014 at 11:51:44PM -0400, Theodore Ts'o wrote:
> On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
> >
> > Short reads are more likely a bug in all the iovec iterator stuff
> > that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
> > stuff go past in to
On Fri, May 03, 2013 at 10:03:43PM +0200, Geert Uytterhoeven wrote:
> Ping?
>
> Now the build failure is also in Linus' tree:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/8674437/
>
> BTW, this patch depends on "[PATCH 1/2] sun3_scsi: Fill in missing
> scsi_host_template.proc_info method"
On Wed, Jan 09, 2008 at 09:55:15PM +0100, Oliver Neukum wrote:
> Hello,
>
> is there a way to distinguish calls to sd_open() from mount() from
> calls to open() ?
No. And there's no way to tell opening external log from either. Or
from swapon. Why the hell would the driver care?
-
To unsubscri
doh...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr_hba.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index acbc50f..d466a2d 100644
--- a/drivers/scsi/
initializing a field in data shared with the card with
cpu_to_le32(something) | 0x10 is broken - the field
is, indeed, little-endian and we need cpu_to_le32() on
both parts.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
1 files chan
a) for type B we should _not_ iounmap() acb->pmu; it's not ioremapped.
b) for type B we should iounmap() two regions we _do_ ioremap.
c) if ioremap() fails, we need to bail out (and clean up).
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcms
driver still has serious portability problems
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr.h | 32 ---
drivers/scsi/arcmsr/arcmsr_attr.c |6 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 170 ++---
3 files change
On Thu, Sep 27, 2007 at 08:45:09AM +0200, Stefan Richter wrote:
> Al Viro wrote:
> > On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote:
> >> Strange. I haven't heard of this before. From which vendor and model
> >> is the device, and do you know which
On Wed, Sep 26, 2007 at 10:55:11PM +0200, Stefan Richter wrote:
> Strange. I haven't heard of this before. From which vendor and model
> is the device, and do you know which chip is on its IDE bridge board?
I've seen it, all right. 8 bytes stuck in FIFO, pl3507 IDE bridge,
and judging by google
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
> } else {
> c->Request.CDBLen = 16;
> c->Request.CDB[1]= 0;
> - c->Request.CDB[2]= (
On Fri, Jul 20, 2007 at 11:50:50AM -0600, Matthew Wilcox wrote:
> On Fri, Jul 20, 2007 at 09:43:47PM +0400, Sergei Shtylyov wrote:
> > Hello Christoph:
> >
> > >>>+#include
> >
> > >>These days that should probably be .
> >
> > >Not at all, linux/irq.h is something entirely different.
> >
> >
On Fri, Jul 20, 2007 at 04:05:30PM -0400, Dave Jones wrote:
> On Fri, Jul 20, 2007 at 04:03:40PM +0100, Al Viro wrote:
> > Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> > ---
> > diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> > index a
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index aebcd5f..7829ab1 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1885,7 +1885,7 @@ static int iscsi_tcp_get_addr(struct iscsi_conn *conn,
struct
On Thu, Jul 05, 2007 at 06:09:27PM -0400, Douglas Gilbert wrote:
> Since a scsi_device object is usually a SCSI logical unit,
> one wonders why it would contain a gendisk object. Logical
> units aren't necessarily disks, they might be enclosures or
> just place holders that respond to an INQUIRY (e
On Thu, Jul 05, 2007 at 02:06:36PM -0700, Kristen Carlson Accardi wrote:
> Since gendisk will now become part of struct scsi_device, we don't need
> to store this value in any private data structs where they already store
> scsi_device. This series cleans up a few drivers which did this.
What the
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/osst.c |8 +++---
drivers/scsi/osst.h | 68 +-
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 7d23110..b
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/iser/iser_initiator.c |4 +-
drivers/scsi/iscsi_tcp.c |2 +-
drivers/scsi/libiscsi.c | 40 +++
include/scsi/iscsi_proto.h
What DMA for 16bit pcmcia card, anyway? We never do request_dma()
there and ->dma_channel never changes since initialization to -1.
IOW, that call is dead code.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/pcmcia/sym53c500_cs.c |2 --
1 files changed, 0 inserti
On Mon, Dec 18, 2006 at 10:34:21AM +0100, Geert Uytterhoeven wrote:
> On Sun, 17 Dec 2006, James Bottomley wrote:
> > On Tue, 2006-10-31 at 22:47 +0100, Kars de Jong wrote:
> > > On ma, 2006-10-30 at 11:13 +, Christoph Hellwig wrote:
> > > > Any updates? Honestly, I do not plan to touch the cu
On Fri, Apr 08, 2005 at 02:41:58PM -0400, Salyzyn, Mark wrote:
> As long as this is guaranteed on all platforms to do the right thing ...
> paranoid about compiler optimizations. MarkH, this should be an easy
> regroup :-)
Well, let's see.
cpu_to_le32(~0U) -> __cpu_to_le32(~0U) ->
[on little-endi
On Fri, Apr 08, 2005 at 08:13:51AM +0100, Christoph Hellwig wrote:
> > + u32 temp = le32_to_cpu(psg->sg[i-1].count) -
> > + (byte_count - scsicmd->request_bufflen);
> > + psg->sg[i-1].count = cpu_to_le32(temp);
>
> You really want {be,
wrong order of arguments in memset().
That, BTW, shows why cross-builds are useful - the only indication of
problem had been a new warning showing up in sparse output on alpha build
(number exceeding 256 got truncated).
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC
On Thu, Feb 03, 2005 at 08:39:22PM -0600, James Bottomley wrote:
> I just got around to applying and testing this. I needed the attached
> to get around the compile warnings it gave me on ia64
>
> I've got to say, it doesn't look pretty to have the block layer
> compat_ioctl returning long but th
spot the typo... It's harmless, in a sense that code compiles right,
but...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC11-rc2-bk10-rme9652/drivers/scsi/aacraid/aachba.c
RC11-rc2-bk10-aacraid/drivers/scsi/aacraid/aachba.c
--- RC11-rc2-bk10-rme9652/drivers/s
54 matches
Mail list logo
