ng like this respin of Kees' series?
>
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup
Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in
weird config cases?
Otherwise, yeah, looks good to me. Thanks!
-Kees
--
Kees Cook
Pixel Security
ere originally.
Honestly, it's almost so small I could make it a static inline. :P
> I'm traveling today so I probably won't get a chance to look closely
> until tomorrow morning.
No worries; thanks for looking at it!
-Kees
--
Kees Cook
Pixel Security
On Wed, May 23, 2018 at 1:25 AM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Hello!
>
> On 5/22/2018 9:15 PM, Kees Cook wrote:
>
>> To avoid introducing problems like those fixed in commit f7068114d45e
>> ("sr: pass down correctly sized SCSI s
about that,
> mostly getting rid of the entire stack dependency.
Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile:
obj-$(CONFIG_SCSI) += scsi/
So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's
scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll
still need to move the code from drivers/scsi/ to block/. Is this
okay?
-Kees
--
Kees Cook
Pixel Security
On Tue, May 22, 2018 at 4:42 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On May 22, 2018, at 5:31 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>>> On 5/22/18 1:13 PM, Chr
On Tue, May 22, 2018 at 4:34 PM, Randy Dunlap <rdun...@infradead.org> wrote:
> On 05/22/2018 04:31 PM, Kees Cook wrote:
>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>> On T
about
>> everyone else, and keep the scsi code where it belongs.
>
> Fine with me then, hopefully we can some day kill it off.
I'll send a v2. I found a few other things to fix up (including the
cdrom.c one).
Thanks!
-Kees
--
Kees Cook
Pixel Security
On Tue, May 22, 2018 at 11:50 AM, Martin K. Petersen
<martin.peter...@oracle.com> wrote:
>
> Christoph,
>
>> On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote:
>>> Both SCSI and ATAPI share the sense header. In preparation for using the
>>>
This drops unused sense buffers from:
cdrom_eject()
cdrom_read_capacity()
cdrom_read_tocentry()
ide_cd_lockdoor()
ide_cd_read_toc()
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/ide/ide-cd.c
Both SCSI and ATAPI share the sense header. In preparation for using the
struct scsi_sense_hdr more widely, move this into a separate header and
move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE
by way of CONFIG_BLK_SCSI_REQUEST.
Signed-off-by: Kees Cook <ke
This is a follow-up to commit f7068114d45e ("sr: pass down correctly
sized SCSI sense buffer") which further cleans up and removes needless
sense character array buffers and "struct request_sense" usage in favor
of the common "struct scsi_sense_hdr".
First, drop a bunch of unused sense buffers:
This removes the unused sense buffer in read_cap16() and write_same16().
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/cxlflash/superpipe.c | 8 ++--
drivers/scsi/cxlflash/vlun.c | 7 ++-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/d
Instead of dynamically allocating the sense buffers, put them on the
stack so that future compile-time sizeof() checks will be able to see
their buffer length.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/ata/libata-scsi.c | 18 ++
1 file changed, 6 inse
those 96 bytes onto the stack to avoid triggering
the sizeof() check.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/scsi_lib.c| 6 +++---
include/scsi/scsi_device.h | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi
dable to distinguish between "sense" meaning "struct request_sense"
and "sshdr" meaning "struct scsi_sense_hdr".
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/block/pktcdvd.c| 36 ++--
drivers/cdrom/cdrom.c
On Wed, May 2, 2018 at 3:21 PM, Kees Cook <keesc...@chromium.org> wrote:
> On the quest to remove all VLAs from the kernel[1] this moves the sg_list
> variable off the stack, as already done for other allocated buffers in
> adpt_i2o_passthru(). Additionally consolidates the error
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
> On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
>> On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
>> > + This used to be the default firmw
ing.
>
> As for the rename that you wanted, perhaps we can do this late in the
> merge window considering we're at rc4 now. I can prep something up for
> that later.
>
> Question, and specially rants are warmly welcomed.
I sent some typo catches, but with those fixed, please c
longer required unless you have a special firmware file that
> - resides in a non-standard path. Moreover, the udev support has
> - been deprecated upstream.
> + Enabling this option forces a sysfs userspace fallback mechanism
> + to be used for all firmware requests which explicitly do not
> disable a
> + a fallback mechanism. Firmware calls which do prohibit a fallback
> + mechanism is request_firmware_direct(). This option is kept for
> + backward compatibility purposes given this precise mechanism can
> also
> + be enabled by setting the proc sysctl value to true:
> +
> + /proc/sys/kernel/firmware_config/force_sysfs_fallback
>
> If you are unsure about this, say N here.
>
> +endif # FW_LOADER
> +endmenu
> +
> config WANT_DEV_COREDUMP
> bool
> help
> --
> 2.17.0
>
-Kees
--
Kees Cook
Pixel Security
://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/ufs/ufshcd.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/d
l.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/osd/osd_initiator.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/
=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/dpt_i2o.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 5ceea8da7bb6..37de8fb186d7 100644
--- a/driver
only found the "what". :) If you want, grab
the reproducer VM linked to earlier in this thread; it'll hit the
problem within about 30 seconds of running the reproducer.
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 3:57 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:48 PM, Jens Axboe wrote:
>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>>> On 4/17/18 3:25 PM, Kees Cook
On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:42 PM, Kees Cook wrote:
>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>> may attempt to read rq->elv fields. When requests got reused, this
>> caus
On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:25 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> I see elv.priv[1] assignments made in a few places -- is it possible
>>&
On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chromium.org> wrote:
> I see elv.priv[1] assignments made in a few places -- is it possible
> there is some kind of uninitialized-but-not-NULL state that can leak
> in there?
Got it. This fixes it for me:
diff --git a/block/b
bfq_insert_request() get called without bfq_prepare_request() being
called first?
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 1:20 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook <keesc...@chromium.org> wrote:
>> The above bfq_dispatch_request+0x99/0xad0 is still
>> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KA
On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook <keesc...@chromium.org> wrote:
> The above bfq_dispatch_request+0x99/0xad0 is still
> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KASAN
> removed. 0x99 is 153 decimal:
>
> (gdb) disass bfq_dispatch_request
>
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook <keesc...@chromium.org> wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook <keesc...@chromium.org> wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901
On Tue, Apr 17, 2018 at 3:02 AM, James Bottomley
<j...@linux.vnet.ibm.com> wrote:
> On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
>> I still haven't figured this out, though... any have a moment to look
>> at this?
>
> Just to let you know you're not alone ...
. Now that I have a
specific place to watch in the kernel for the corruption, though, that
might help. If I get stuck again today, I'll try it.
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 16, 2018 at 1:44 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> After fixing up some build is
On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>> After fixing up some build issues in the middle of the 4.16 cycle, I
>> get an unhelpful bisect result of commit
On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
> After fixing up some build issues in the middle of the 4.16 cycle, I
> get an unhelpful bisect result of commit 0a4b6e2f80aa ("Merge branch
> 'for-4.16/block'"). Instead of letting the t
On Thu, Apr 12, 2018 at 3:01 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
> <oleksa...@natalenko.name> wrote:
>> Hi.
>>
>> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>>> My fir
On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi.
>
> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>> My first bisect attempt gave me commit 5448aca41cd5 ("null_blk: wire
>> up timeouts"), which seems
On Wed, Apr 11, 2018 at 5:03 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> I'll see about booting with my
On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
>> I'll see about booting with my own kernels, etc, and try to narrow this
>> down. :)
>
> If I boot kernels I'
On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
> I'll see about booting with my own kernels, etc, and try to narrow this down.
> :)
If I boot kernels I've built, I no longer hit the bug in this VM
(though I'll keep trying). What compiler are you using?
-Ke
On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :
uce it since. :(
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 9, 2018 at 1:30 PM, Kees Cook <keesc...@chromium.org> wrote:
> Ah! dm-crypt too. I'll see if I can get that added easily to my tests.
Quick update: I added dm-crypt (with XFS on top) and it hung my system
almost immediately. I got no warnings at all, though.
-Kees
--
On Mon, Apr 9, 2018 at 12:02 PM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
>
> Hi.
>
> (fancy details for linux-block and BFQ people go below)
>
> 09.04.2018 20:32, Kees Cook wrote:
>>
>> Ah, this detail I didn't have. I've c
eba1ab2cc9f45668735
The thing I can't figure out is how req->sense is slipping forward in
(and even beyond!) the allocation.
-Kees
--
Kees Cook
Pixel Security
rtctl -a /dev/sda; smartctl -a /dev/sdb ) > /dev/null;
done &
I assume I'm missing something from your .config, but since I don't
boot with an initramfs, I had to tweak it a bit. I'll try again...
-Kees
--
Kees Cook
Pixel Security
On Thu, Apr 5, 2018 at 2:56 AM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi.
>
> 04.04.2018 23:25, Kees Cook wrote:
>>
>> Thanks for the report! I hope someone more familiar with sg_io() can
>> help explain the changing buffer offset... :P
>
>
On Wed, Apr 4, 2018 at 1:49 PM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi.
>
> On středa 4. dubna 2018 22:21:53 CEST Kees Cook wrote:
>>
>> ...
>> That means scsi_sense_cache should be 96 bytes in size? But a 22 byte
>> read starting at o
hat ioctl()s smartctl is issuing? I'll try to
reproduce this on my end...
-Kees
--
Kees Cook
Pixel Security
y trick of silently
expanding its allocation into the space the slab allocator has given
it? If not, this looks like a real bug.
What I don't see is how req->sense is _not_ at offset 0 in the
scsi_sense_cache object...
-Kees
--
Kees Cook
Pixel Security
this can be replaced by the product of the
> size of an element and the number of elements, avoiding the VLA
> altogether.
>
> This was prompted by https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Stephen Kitt <st...@sk2.org>
Reviewed-by: Kees Cook <keesc...@chromium.org&g
ar so to the compiler. Replace the array
> sizes with a pre-processor-level constant instead using ARRAY_SIZE.
>
> This was prompted by https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Stephen Kitt <st...@sk2.org>
Thanks!
Reviewed-by: Kees Cook <keesc...@chromi
-static const int num_critical_sections = sizeof(critical_sections)
> - / sizeof(*critical_sections);
> +#define NUM_CRITICAL_SECTIONS 14
The compiler doesn't treat "const" as a literal, hence the need to
change this. However, you can still use the sizeof (actually, this is
exactly ARRAY_SIZE()). Perhaps:
#define NUM_CRITICAL_SECTIONS ARRAY_SIZE(critical_sections)
?
Otherwise, looks great!
-Kees
--
Kees Cook
Pixel Security
" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/scsi_lib.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1
" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/scsi_lib.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1cbc497e00bd..1
lize in
> REC action trace").
>
> However, they do apply to Linus' tree for v4.14-rc7 or later and
> thus they would also apply for the upcoming merge window.
>
> In http://www.spinics.net/lists/linux-scsi/msg114581.html I saw a decision
> to have such changes go in v
On Tue, Oct 31, 2017 at 12:13 PM, Kees Cook <keesc...@chromium.org> wrote:
> This breaks out the logical steps to convert the qla2xxx timers:
>
> 1) init_timer() -> setup_timer()
> 2) refactor qla2x00_start_timer() to not pass callback as argument
> 3) qla2x00_timer()
adh...@cavium.com>
Cc: Bart Van Assche <bart.vanass...@wdc.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla2xxx/qla_gbl.h| 2 +-
dri
gt;
Cc: Bart Van Assche <bart.vanass...@wdc.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla2xxx/qla_gbl.h | 2 +-
drivers/sc
rt Van Assche <bart.vanass...@wdc.com>
Cc: qla2xxx-upstr...@qlogic.com
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla2xxx/qla_inline.h | 5 ++---
drivers/scsi/qla2x
rt.vanass...@wdc.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla2xxx/qla_gbl.h | 2 +-
drivers/scsi/qla2xxx/qla_mid.c | 2 +-
drivers/sc
This breaks out the logical steps to convert the qla2xxx timers:
1) init_timer() -> setup_timer()
2) refactor qla2x00_start_timer() to not pass callback as argument
3) qla2x00_timer() to use timer_setup()
4) qla2x00_sp_timeout() to use timer_setup()
The resulting diff is identical to the patch
On Tue, Oct 31, 2017 at 11:36 AM, Madhani, Himanshu
<himanshu.madh...@cavium.com> wrote:
> Hi Kees,
>
>> On Oct 31, 2017, at 11:28 AM, Kees Cook <keesc...@chromium.org> wrote:
>>
>> How very strange. I don't see any code change with this patch. Even
>> th
gt;
>
> Here’s my setup details
>
> 4.14.0-rc7 + scsi_misc-4.15 qla2xxx patches from Martin’s tree + current
> patch.
>
> System has 3 adapters 8G/16G/32G.
>
>> Anyway, what kernel source tree did you use in your testing? I may be able to
>> free up some time to look into this myself.
>>
>> Bart.
>
> Thanks,
> - Himanshu
--
Kees Cook
Pixel Security
patch is identical to the patch I posted in May 2017.
>
> OK. Just checking.
>
> So what's the plan here? Should both patches be routed through the timer
> tree?
That was my plan. Does that sound okay?
-Kees
--
Kees Cook
Pixel Security
On Fri, Oct 27, 2017 at 5:57 AM, Bart Van Assche <bart.vanass...@wdc.com> wrote:
> On Fri, 2017-10-27 at 02:19 -0700, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_s
nux-iscsi.org>
Cc: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: Jiang Yi <jiangyil...@gmail.com>
Cc: Varun Prakash <va...@chelsio.com>
Cc: linux-scsi@vger.kernel.org
Cc: target-de...@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This is rebased on t
On Thu, Oct 26, 2017 at 4:04 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote:
> On Thu, 2017-10-26 at 10:24 +0200, Kees Cook wrote:
>> On Wed, Oct 25, 2017 at 5:03 PM, Bart Van Assche <bart.vanass...@wdc.com>
>> wrote:
>> > On Wed, 2017-10-25 at 16:10 +0
On Wed, Oct 25, 2017 at 5:03 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote:
> On Wed, 2017-10-25 at 16:10 +0200, Kees Cook wrote:
>> However, maintainers: sorry to send this one -- it can't be merged
>> yet, this uses timer_setup_on_stack() which is only in -next righ
On Wed, Oct 25, 2017 at 2:41 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
> On Wed, Oct 25, 2017 at 12:01 PM, Kees Cook <keesc...@chromium.org> wrote:
>> sess->time2retain_timer.expires =
>> (get_jiffies_64() + sess->
.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 8
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 8
drivers/scsi/cxgbi/libcxgbi.c
; <j...@linux.vnet.ibm.com>
Cc: Varun Prakash <va...@chelsio.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/csiostor/csio_hw.c | 15 ++-
drivers/scsi/csiostor/csio_mb
: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/lpfc/lpfc_crtn.h| 16
drivers/scs
t;
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla2xxx/qla_gbl.h| 6 +++---
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_inline.h | 4 +---
t;
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/qla4xxx/ql4_os.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql
lt;martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/pmcraid.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
i
;
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
Cc: Benjamin Block <bbl...@linux.vnet.ibm.com>
Cc: Baoyou Xie <baoyou@linaro.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <kees
t;martin.peter...@oracle.com>
Cc: megaraidlinux@broadcom.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/megaraid/megaraid_ioctl.h | 6 +
drivers/scsi/megaraid/megaraid_mbox.c | 26 ++---
drivers/scsi/megaraid/megarai
ux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-...@lists.oz
.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/ipr.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/i
t;
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: Johannes Thumshirn <j...@kernel.org>
Cc: linux-scsi@vger.kernel.org
Cc: fcoe-de...@open-fcoe.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
Acked-by: Johannes Thumshirn <j...@kernel.or
ttomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/aic7xxx/aic79xx.h | 5 +
drivers/scsi/aic7xxx/aic79xx_core.c | 29 +++
nux-iscsi.org>
Cc: Jiang Yi <jiangyil...@gmail.com>
Cc: Varun Prakash <va...@chelsio.com>
Cc: Bart Van Assche <bart.vanass...@sandisk.com>
Cc: "Jason A. Donenfeld" <ja...@zx2c4.com>
Cc: Al Viro <v...@zeniv.linux.org.uk>
Cc: linux-scsi@vger.kernel.org
Cc: targ
4.15 queue this late in the cycle
> so the patches would end up going in at the end of the merge window. If
> you prefer to have them hit the first pull you should queue them up in
> the timer tree.
Okay, thanks, I'll take them via the timer tree.
-Kees
--
Kees Cook
Pixel Security
pass the timer pointer explicitly.
>
> Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com>
Thanks for the reviews! Do you want the timer tree to carry these
patches, or can you pick them up in the scsi tree?
-Kees
--
Kees Cook
Pixel Security
: Johannes Thumshirn <j...@kernel.org>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: fcoe-de...@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.o
the open-coded initialization.
Cc: qlogic-storage-upstr...@qlogic.com
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
m.com>
Cc: Jitendra Bhivare <jitendra.bhiv...@broadcom.com>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
dr
; <j...@linux.vnet.ibm.com>
Cc: Tomas Henzl <the...@redhat.com>
Cc: Quentin Lambert <lambert.quen...@gmail.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +--
drivers/scsi/aic94xx/aic94xx_hwi.h |
.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: open-is...@googlegroups.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/libiscsi.c | 16 ++--
1 file cha
emi.com>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: esc.storage...@microsemi.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/smartpqi/smartpqi_init.c | 9 -
1 file changed, 4 insertions(+), 5 dele
ux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/gdth.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/
enehan <lene...@twibble.org>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: dc3...@twibble.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/dc395x.
ux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-...@lists.oz
ttomley" <j...@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callbac
lt;martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callback argument type") in v4.14-rc3, but should be o
;
Cc: Hannes Reinecke <h...@suse.com>
Cc: Johannes Thumshirn <jthumsh...@suse.de>
Cc: Benjamin Block <bbl...@linux.vnet.ibm.com>
Cc: Baoyou Xie <baoyou@linaro.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: linux-scsi@vger.kernel.org
Cc: Thomas Gleixner <t...@linut
.com>
Cc: "Martin K. Petersen" <martin.peter...@oracle.com>
Cc: linux-scsi@vger.kernel.org
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This requires commit 686fef928bba ("timer: Prepare to change timer
callback argu
1 - 100 of 156 matches
Mail list logo
