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/scsi/aacraid
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 the
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 RC11-rc3-bk8
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-endian]
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 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 do with
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 EOF
/iov_iter_truncate/s/size_t/u64/
w
q
EOF
Could you check if that fixes the sucker?
The following patch (attached at the end
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
@@ -94,7 +94,7
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 after sending
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 count is. They are compared as natural
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
confirmation that this one-liner actually
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 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 chip is on its IDE bridge board
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 changed, 103
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/arcmsr.h |9 -
drivers
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 changed, 1
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/arcmsr
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]
---
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 socket
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 asm/irq.h
These days that should probably be linux/irq.h.
Not at all, linux/irq.h is something entirely different.
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]=
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 insertions(+), 2
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 unsubscribe
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:06:24AM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
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
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 n...@linux-iscsi.org
This patch adds a new memcpy_fromiovec_out() library function which modifies
the passed *iov following
ouldn't be equivalent to the ability to trigger
BUG_ON() while holding spinlocks...
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
---
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index dbe5b4b95df0..121de0aaa6ad 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scs
On Mon, Dec 05, 2016 at 04:17:53PM +0100, Johannes Thumshirn wrote:
> 633 hp = >header;
> [...]
> 646 hp->dxferp = (char __user *)buf + cmd_size;
> So the memory for hp->dxferp comes from:
> 633 hp = >header;
> >From my debug instrumentation I see that the
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
On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
> Since right after the user copy, we are going to
> memset(, 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)
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,
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;
>
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.
>
>
33 matches
Mail list logo
