vers/net/ethernet/sun/sunhme.c | 4 ++--
> drivers/scsi/qlogicpti.h | 2 +-
> fs/notify/inotify/inotify_user.c | 2 +-
> kernel/irq/timings.c | 2 +-
> lib/vsprintf.c| 2 +-
> net/core/skbuff.c | 2 +-
> 17 files changed, 33 insertions(+), 31 deletions(-)
>
> --
> 2.19.1
>
--
Kees Cook
On Wed, Oct 31, 2018 at 9:19 PM, Souptick Joarder wrote:
> Replaced dma_pool_alloc + memset with dma_pool_zalloc
>
> Signed-off-by: Brajeswar Ghosh
> Signed-off-by: Souptick Joarder
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +--
&g
On Tue, Sep 11, 2018 at 12:22 PM, Laura Abbott wrote:
>
> While reviewing another part of the code, Kees noticed that the
> strncpy of the partition name might not always be NUL terminated. Switch
> to using strscpy which does this safely.
>
> Reported-by: Kees Cook
> Signed
On Tue, Sep 11, 2018 at 11:24 AM, Kees Cook wrote:
> On Tue, Sep 11, 2018 at 11:05 AM, Laura Abbott wrote:
>>
>> There's currently a warning about string overflow with strncat:
>>
>> drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis
On Tue, Sep 11, 2018 at 11:15 AM, Laura Abbott wrote:
> While reviewing another part of the code, Kees noticed that the
> strncpy of the partition name might not always be NUL terminated. Switch
> to using strlcpy which does this safely.
>
> Reported-by: Kees Cook
> Signed-of
trncat' specified
> bound 64 equals destination size [-Werror=stringop-overflow=]
> strncat(vscsi->eye, vdev->name, MAX_EYE);
> ^~~~
>
> Switch to a single snprintf instead of a strcpy + strcat to handle this
> cleanly.
>
> Si
s' 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
put the function in there 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
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 sense buffer"), this creates a macro
t,
> 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 wrote:
> On May 22, 2018, at 5:31 PM, Kees Cook wrote:
>>
>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>>> On Tue, May 22, 2018 at 01:09:41PM
On Tue, May 22, 2018 at 4:34 PM, Randy Dunlap wrote:
> On 05/22/2018 04:31 PM, Kees Cook wrote:
>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote:
>>> On 5/22/18 1:13 PM, Christoph Hellwig wrote:
>>>> On Tue, May 22, 2018 at 01:09:41PM -0600, Jens Axboe w
ut
>> 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
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
>>> struct scsi_sense_hdr more widely, mov
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
---
drivers/ide/ide-cd.c | 36 +++-
drivers/ide/ide-cd.h
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
---
block
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
---
drivers/scsi/cxlflash/superpipe.c | 8 ++--
drivers/scsi/cxlflash/vlun.c | 7 ++-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxlflash/superpipe.c
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
---
drivers/ata/libata-scsi.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff
those 96 bytes onto the stack to avoid triggering
the sizeof() check.
Signed-off-by: Kees Cook
---
drivers/scsi/scsi_lib.c| 6 +++---
include/scsi/scsi_device.h | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.
dable to distinguish between "sense" meaning "struct request_sense"
and "sshdr" meaning "struct scsi_sense_hdr".
Signed-off-by: Kees Cook
---
drivers/block/pktcdvd.c| 36 ++--
drivers/cdrom/cdrom.c | 22 +++-
On Wed, May 2, 2018 at 3:21 PM, Kees Cook 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 path for kfree().
>
&g
On Wed, May 9, 2018 at 1:55 PM, Luis R. Rodriguez 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 wrote:
>> > + This used to be the default firmware loading facility, and udev
>> > us
gt; 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 consider the
whole series:
Reviewed-by: Kees Cook
Thanks!
-Kees
--
Kees Cook
Pixel Security
er 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
---
drivers/scsi/ufs/ufshcd.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index
kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/scsi/osd/osd_initiator.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
ind
=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
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/drivers/scsi/dpt_i2o.c
+++ b/drivers
t;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 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 wrote:
>>>> On 4/17/18 3:25 PM, Kees Cook wrote:
>>>>> On Tue, Apr 17
On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe 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
>> caused BFQ to think it alr
On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote:
> On 4/17/18 3:25 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote:
>>> I see elv.priv[1] assignments made in a few places -- is it possible
>>> there is some kind of uninitialized-but-not-NULL
Reported-by: Oleksandr Natalenko
Fixes: bd166ef183c26 ("blk-mq-sched: add framework for MQ capable IO
schedulers")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
In theory, BFQ needs to also check the RQF_ELVPRIV flag, but I'll leave that
to Paolo to figure out. Also, my Fixe
On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook 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/blk-mq.c b/block/blk-m
t_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 wrote:
> On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook 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 decima
On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook 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
> Dump of assembler
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook 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) {
> 3901inc_in_
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook 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) {
> 3901inc_in_
On Tue, Apr 17, 2018 at 3:02 AM, James Bottomley
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 ... but I can't make a
ic 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 wrote:
> On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook wrote:
>> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook wrote:
>>> After fixing up some build issues in the middle of the 4.16 cycle, I
>>> get an unhelpful bisect result of
On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook wrote:
> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook 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&
On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook 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 test run longer, I'm
On Thu, Apr 12, 2018 at 3:01 PM, Kees Cook wrote:
> On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
> 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
On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
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 insane given that null_blk isn&#x
On Wed, Apr 11, 2018 at 5:03 PM, Kees Cook wrote:
> On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook wrote:
>> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook wrote:
>>> I'll see about booting with my own kernels, etc, and try to narrow this
>>> down. :)
>>
>&g
On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook wrote:
> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook 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
&g
On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook 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?
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
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. :(
>
>
> For your conve
On Mon, Apr 9, 2018 at 11:35 PM, Oleksandr Natalenko
wrote:
> Did your system hang on smartctl hammering too? Have you got some stack
> traces to compare with mine ones?
Unfortunately I only had a single hang with no dumps. I haven't been
able to reproduce it since. :(
-Kees
--
On Mon, Apr 9, 2018 at 1:30 PM, Kees Cook 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
--
Kees Cook
Pixel Security
On Mon, Apr 9, 2018 at 12:02 PM, Oleksandr Natalenko
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 changed my environment to
>
6f58f8891468aeba1ab2cc9f45668735
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
/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
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
>
>
> Also, FYI, I kept the serve
On Wed, Apr 4, 2018 at 1:49 PM, Oleksandr Natalenko
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 offset 94 happened? That seems like
ng? I'll try to
reproduce this on my end...
-Kees
--
Kees Cook
Pixel Security
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
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
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/bfa/bfad_bsg.c | 2 +-
>
r. 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
Thanks!
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/scsi/aic7xxx/aic79xx_core.c
ctions = 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
ing
cache-managed memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
dri
ing
cache-managed memory falls entirely within the slab's usercopy region.
Signed-off-by: David Windsor
[kees: adjust commit log, provide usage trace]
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
dri
C 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 via the timer
On Tue, Oct 31, 2017 at 12:13 PM, Kees Cook 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() to use timer_setup()
> 4) ql
: "Martin K. Petersen"
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla2xxx/qla_gbl.h| 2 +-
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_inline.h | 3 +--
3 files changed, 4 insertions(+), 5 deletion
: "Martin K. Petersen"
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla2xxx/qla_gbl.h | 2 +-
drivers/scsi/qla2xxx/qla_os.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/dr
...@qlogic.com
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla2xxx/qla_inline.h | 5 ++---
drivers/scsi/qla2xxx/qla_os.c | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_inline.h
b/dr
2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla2xxx/qla_gbl.h | 2 +-
drivers/scsi/qla2xxx/qla_mid.c | 2 +-
drivers/scsi/qla2xxx/qla_os.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h
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 th
On Tue, Oct 31, 2017 at 11:36 AM, Madhani, Himanshu
wrote:
> Hi Kees,
>
>> On Oct 31, 2017, at 11:28 AM, Kees Cook wrote:
>>
>> How very strange. I don't see any code change with this patch. Even
>> the passed arguments are the same; it's only enforcing
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
d 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 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_setup() and from_timer()
>> to p
Assche
Cc: Jiang Yi
Cc: Varun Prakash
Cc: linux-scsi@vger.kernel.org
Cc: target-de...@vger.kernel.org
Signed-off-by: Kees Cook
---
This is rebased on top of Bart's timer clean-up patch:
https://www.spinics.net/lists/target-devel/msg15385.html
---
drivers/target/iscsi/iscsi_targ
On Thu, Oct 26, 2017 at 4:04 PM, Bart Van Assche 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
>> wrote:
>> > On Wed, 2017-10-25 at 16:10 +0200, Kees Cook wrote:
>> > > However, maintainers: s
On Wed, Oct 25, 2017 at 5:03 PM, Bart Van Assche 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 right
>> now. If it looks
On Wed, Oct 25, 2017 at 2:41 PM, Jason A. Donenfeld wrote:
> On Wed, Oct 25, 2017 at 12:01 PM, Kees Cook wrote:
>> sess->time2retain_timer.expires =
>> (get_jiffies_64() + sess->sess_ops->DefaultTime2Retain * HZ);
>> add_
er.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c | 8
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 8
drivers/scsi/cxgbi/libcxgbi.c | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
b/drivers/scsi/c
Thumshirn
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/csiostor/csio_hw.c | 15 ++-
drivers/scsi/csiostor/csio_mb.c | 9 +++--
drivers/scsi/csiostor/csio_mb.h | 3 ++-
3 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/
uot;
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/lpfc/lpfc_crtn.h| 16
drivers/scsi/lpfc/lpfc_ct.c | 4 ++--
drivers/scsi/lpfc/lpfc_els.c | 12 ++--
drivers/scsi/lpfc/lpfc_hbadisc.c | 7 +++
drivers/scsi/lpfc
uot;
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla2xxx/qla_gbl.h| 6 +++---
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_inline.h | 4 +---
drivers/scsi/qla2xxx/qla_mid.c| 2 +-
drivers/scsi/qla2xxx/qla_os.c | 11 +--
uot;
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/qla4xxx/ql4_os.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 64c6fa563fdb..2b8a8ce2a431 100644
--- a/drivers/s
tion = (void (*)(unsigned long))pmcraid_timeout_handler;
+ cmd->timer.function = (TIMER_FUNC_TYPE)pmcraid_timeout_handler;
if (!timer_pending(&cmd->timer))
add_timer(&cmd->timer);
--
2.7.4
--
Kees Cook
Pixel Security
slow_task.
Cc: John Garry
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: Jack Wang
Cc: lindar_...@usish.com
Cc: Jens Axboe
Cc: Hannes Reinecke
Cc: Johannes Thumshirn
Cc: Benjamin Block
Cc: Baoyou Xie
Cc: Wei Yongjun
Cc: linux-scsi@vger.kernel.org
Signed-off-by
usage.
Cc: Kashyap Desai
Cc: Sumit Saxena
Cc: Shivasharan S
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: megaraidlinux@broadcom.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/megaraid/megaraid_ioctl.h | 6 +
d
c: Michael Ellerman
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Kees Cook
---
drivers/scsi/ibmvscsi/ibmvfc.c | 14 ++
drivers/scsi/ibmvscsi/ibmvscsi.c | 7 +++
2 files changed, 9 insertions(+), 12 deleti
er.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/ipr.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index f838bd73befa..d53429371127 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ip
"
Cc: Johannes Thumshirn
Cc: linux-scsi@vger.kernel.org
Cc: fcoe-de...@open-fcoe.org
Signed-off-by: Kees Cook
Acked-by: Johannes Thumshirn
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 11 +--
drivers/scsi/fcoe/fcoe.c | 2 +-
drivers/scsi/fcoe/fcoe_transport.c | 6 --
in
"Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/aic7xxx/aic79xx.h | 5 +
drivers/scsi/aic7xxx/aic79xx_core.c | 29 -
drivers/scsi/aic7xxx/aic79xx_osm.h | 7 ---
3 files changed, 9 insertions(+), 32 deleti
Cc: Varun Prakash
Cc: Bart Van Assche
Cc: "Jason A. Donenfeld"
Cc: Al Viro
Cc: linux-scsi@vger.kernel.org
Cc: target-de...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/target/iscsi/iscsi_target_erl0.c | 9 -
drivers/target/iscsi/iscsi_target_erl1.c | 8 +++-
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
.
>
> Reviewed-by: Martin K. Petersen
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
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: fcoe-de...@open-fcoe.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/libfc/fc_fcp.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git
open-coded initialization.
Cc: qlogic-storage-upstr...@qlogic.com
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/bnx2i/bnx2i.h | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 4 ++--
"Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/be2iscsi/be_main.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 7561e1332257.
bert
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/aic94xx/aic94xx_hwi.c | 3 +--
drivers/scsi/aic94xx/aic94xx_hwi.h | 5 ++---
drivers/scsi/aic94xx/aic94xx_scb.c | 6 +++---
drivers/scsi/aic94xx/aic94xx_tmf.c | 13 ++---
4 files changed, 12 insertions(+), 1
n"
Cc: open-is...@googlegroups.com
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/libiscsi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index f8dc1601efd5..9c50d2d9f27c 10064
scsi@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/scsi/gdth.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index a4473356a9dc..c35f05c4c6bb 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -3705,7 +3
1 - 100 of 163 matches
Mail list logo
