[PATCH blktests] scsi/004: add regression test for false BLK_STS_OK with non good SAM status

Signed-off-by: Steffen Maier --- tests/scsi/004 | 59 tests/scsi/004.out |3 ++ 2 files changed, 62 insertions(+), 0 deletions(-) create mode 100755 tests/scsi/004 create mode 100644 tests/scsi/004.out diff

Re: MPT Fusion - ext4 delayed allocation failed errors on 4.14!

On Mon, 2018-04-16 at 23:25 -0400, Martin K. Petersen wrote: > Nikola, > > > thanks for explanation. but disabling write same for now is safe, > > right? > > I was hoping we'd be able to disable it for SATA devices only. > > > root@siv-70140:~ # sg_vpd /dev/sda > > Supported VPD pages VPD page:

Re: [PATCH blktests] scsi/004: add regression test for false BLK_STS_OK with non good SAM status

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: usercopy whitelist woe in scsi_sense_cache

Hi. 17.04.2018 05:12, Kees Cook wrote: Turning off HARDENED_USERCOPY and turning on KASAN, I see the same report: [ 38.274106] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x42/0x60 [ 38.274841] Read of size 22 at addr 8800122b8c4b by task smartctl/1064 [ 38.275630] [

Re: usercopy whitelist woe in scsi_sense_cache

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 any sense of this either. The bfdq is the elevator_data, which is initialised when the scheduler is

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

Hi, Steve Right, Please see below portion log from ftrace and blktrace, There is no any impact on blktrace. > >Looking at the code from >git://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git > >It appears that it does not rely on the ftrace ring buffers. > >So I'm guessing blktrace is

Re: Add udev-md-raid-safe-timeouts.rules

On 2018-04-16 13:10, Chris Murphy wrote: Adding linux-usb@ and linux-scsi@ (This email does contain the thread initiating email, but some replies are on the other lists.) On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn wrote: On 2018-04-15 21:04, Chris Murphy

[PATCH 1/1] scsi: sd: improved drive sanitize error handling

During the drive sanitization, when the sd driver issues TEST UNIT READY (TUR), drive reports Sense Key: NOT_READY, ASC: 0x4 and ASCQ: 0x1b. Sd driver issuing START_STOP command to spin up the drive. This causes a hung and call trace occurred. sd driver should take note of Sense Key: NOT_READY,

[PATCH v9 5/5] arm64: defconfig: enable f2fs and squashfs

Partitions in HiKey960 are formatted as f2fs and squashfs. f2fs is for userdata; squashfs is for system. Both partitions are required by Android. Signed-off-by: Li Wei Signed-off-by: Zhangfei Gao Signed-off-by: Guodong Xu ---

[PATCH v9 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC

This patchset adds driver support for UFS for Hi3660 SoC. It is verified on HiKey960 board. Li Wei (5): scsi: ufs: add Hisilicon ufs driver code dt-bindings: scsi: ufs: add document for hisi-ufs arm64: dts: add ufs dts node arm64: defconfig: enable configs for Hisilicon ufs arm64:

[PATCH v2] target: Fix Fortify_panic kernel exception

The bug exists in the memcmp in which the length passed in must be guaranteed to be 1. This bug currently exists because the second pointer passed in, can be smaller than the cmd->data_length, which causes a fortify_panic. The fix is to use memchr_inv instead to find whether or not a 0 exists

Re: usercopy whitelist woe in scsi_sense_cache

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_driver_start_rq: >

Re: usercopy whitelist woe in scsi_sense_cache

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 any sense of >

Re: [PATCH] target: fix crash with iscsi target and dvd

Looks good, Reviewed-by: Christoph Hellwig Btw, seems like someone needs to volunteer for putting together a pull request with target fixes for Linus - I haven't heard from Nic for a while, and we've got quite a few fixes out on the list.

Re: [PATCHv3] tcmu: allow userspace to reset netlink

Nick, Ignore this v3 too. It will not work for deletion. On 04/16/2018 07:43 AM, xiu...@redhat.com wrote: > From: Xiubo Li > > This patch adds 1 tcmu attr to reset and complete all the blocked > netlink waiting threads. It's used when the userspace daemon like > tcmu-runner

Re: usercopy whitelist woe in scsi_sense_cache

On 4/17/18 10:42 AM, Kees Cook wrote: > 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 >> 3900

Re: [PATCH] target: Fix Fortify_panic kernel exception

On 4/13/18 11:44 AM, Christoph Hellwig wrote: > The patch looks fine, but in general I think descriptions of what > you fixed in the code or more important than starting out with > a backtrace. > > E.g. please explain what was wrong, how you fixed it and only after > that mention how it was

Re: [PATCH] target: Fix Fortify_panic kernel exception

On Tue, Apr 17, 2018 at 10:18:17AM -0500, Bryant G. Ly wrote: > > On 4/13/18 11:44 AM, Christoph Hellwig wrote: > > > The patch looks fine, but in general I think descriptions of what > > you fixed in the code or more important than starting out with > > a backtrace. > > > > E.g. please explain

Re: usercopy whitelist woe in scsi_sense_cache

On Tue, Apr 17, 2018 at 2:19 AM, Oleksandr Natalenko wrote: > By any chance, have you tried to simplify the reproducer environment, or it > still needs my complex layout to trigger things even with KASAN? I haven't tried minimizing the reproducer yet, no. Now that I

[PATCH v9 3/5] arm64: dts: add ufs dts node

arm64: dts: add ufs node for Hisilicon. Signed-off-by: Li Wei --- arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi index

[PATCH v9 1/5] scsi: ufs: add Hisilicon ufs driver code

add Hisilicon ufs driver code. Signed-off-by: Li Wei Signed-off-by: Geng Jianfeng Signed-off-by: Zang Leigang Signed-off-by: Yu Jianfeng --- drivers/scsi/ufs/Kconfig| 9 +

[PATCH v9 4/5] arm64: defconfig: enable configs for Hisilicon ufs

This enable configs for Hisilicon Hi UFS driver. Signed-off-by: Li Wei Signed-off-by: Zhangfei Gao Signed-off-by: Guodong Xu --- arch/arm64/configs/defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: usercopy whitelist woe in scsi_sense_cache

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_driver_start_rq: >

[PATCH] bsg referencing bus driver module

Description: bsg_release may crash while decrementing reference to the parent device with the following stack: [16834.636216,07] Call Trace: ... scsi_proc_hostdir_rm [16834.641944,07] [] scsi_host_dev_release+0x3f/0x130 [16834.647740,07] []

Re: usercopy whitelist woe in scsi_sense_cache

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 code for

Re: usercopy whitelist woe in scsi_sense_cache

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

Re: [PATCH 3/3] sd_zbc: Avoid that resetting a zone fails sporadically

On 2018/04/16 18:04, Bart Van Assche wrote: > Since SCSI scanning occurs asynchronously, since sd_revalidate_disk() > is called from sd_probe_async() and since sd_revalidate_disk() calls > sd_zbc_read_zones() it can happen that sd_zbc_read_zones() is called > concurrently with

Re: [PATCH 1/1] scsi/ufs: qcom: Don't enable PHY_QCOM_UFS by default

On Mon 09 Apr 23:31 PDT 2018, Vivek Gautam wrote: > > > On 4/10/2018 1:39 AM, Bjorn Andersson wrote: > > On Mon 09 Apr 10:38 PDT 2018, Vivek Gautam wrote: > > > On 4/9/2018 10:21 PM, Bjorn Andersson wrote: > > > > On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote: > > [..] > > > > > diff --git

Re: [PATCH 1/3] sd_zbc: Change the type of the ZBC fields into u32

On 2018/04/16 18:04, Bart Van Assche wrote: > This patch does not change any functionality but makes it clear > that it is on purpose that these fields are 32 bits wide. > > Signed-off-by: Bart Van Assche > Cc: Damien Le Moal > Cc: Christoph

Re: [PATCH 2/3] sd_zbc: Let the SCSI core handle ILLEGAL REQUEST / ASC 0x21

On 2018/04/16 18:04, Bart Van Assche wrote: > scsi_io_completion() translates the sense key ILLEGAL REQUEST / ASC > 0x21 into ACTION_FAIL. That means that setting cmd->allowed to zero > in sd_zbc_complete() for this sense code / ASC combination is not > necessary. Hence remove the code that resets

Re: usercopy whitelist woe in scsi_sense_cache

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, 2018 at 1:46 PM, Kees Cook wrote: > I see elv.priv[1]

Re: [PATCH] blk-mq: Clear out elevator private data

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 already had a bfqq

Re: [PATCH] blk-mq: Clear out elevator private data

On 4/17/18 4:57 PM, Kees Cook wrote: > 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 >>>

Re: usercopy whitelist woe in scsi_sense_cache

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, 2018 at 1:46

Re: usercopy whitelist woe in scsi_sense_cache

On 4/17/18 5:06 PM, Kees Cook wrote: > 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

Re: usercopy whitelist woe in scsi_sense_cache

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 state that can leak >> in there? > > Got it. This fixes it

Re: usercopy whitelist woe in scsi_sense_cache

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, 2018 at 1:46 PM, Kees Cook wrote: I see elv.priv[1] assignments made in a few places -- is it

Re: usercopy whitelist woe in scsi_sense_cache

On 4/17/18 2:25 PM, Kees Cook wrote: > 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

Re: usercopy whitelist woe in scsi_sense_cache

On Tue, Apr 17, 2018 at 1:28 PM, Jens Axboe wrote: > It has to be the latter bfqq->dispatched increment, as those are > transient (and bfqd is not). Yeah, and I see a lot of comments around the lifetime of rq and bfqq, so I assume something is not being locked correctly.

Re: [PATCH] blk-mq: Clear out elevator private data

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 already had a bfqq (rq->elv.priv[1]) allocated. > This could lead to odd behaviors like having

Re: usercopy whitelist woe in scsi_sense_cache

Hi. 17.04.2018 23:47, Kees Cook wrote: I sent the patch anyway, since it's kind of a robustness improvement, I'd hope. If you fix BFQ also, please add: Reported-by: Oleksandr Natalenko Root-caused-by: Kees Cook :) I gotta task-switch to other

Re: usercopy whitelist woe in scsi_sense_cache

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

Re: usercopy whitelist woe in scsi_sense_cache

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

Re: MPT Fusion - ext4 delayed allocation failed errors on 4.14!

James, >> However, it doesn't look like we have much to work with since there >> is no ATA Information VPD page exposed. > > it's the fat firmware problem again. However, the driver does know, so > could we persuade a modification of > mpt3sas_scsih.c:_scsih_display_sata_capabilities() to

[PATCH v3 1/6] ilog2: create truly constant version for sparse

Sparse emits errors about ilog2() in array indices because of the use of __ilog2_32() and __ilog2_64(), rightly so (https://www.spinics.net/lists/linux-sparse/msg03471.html). Create a const_ilog2() variant that works with sparse for this scenario. (Note: checkpatch.pl complains about missing

[PATCH v3 0/6] scsi: handle special return codes for ABORTED COMMAND

Here is another attempt to handle the special return codes for ABORTED COMMAND for certain SCSI devices. Following MKP's recommendation, I've created two new BLIST flags, simplifying the code in scsi_error.c compared to the previous versions. Rather than using "free" bits, I increased the length

Re: [PATCH v3 1/6] ilog2: create truly constant version for sparse

On Tue, Apr 17, 2018 at 4:35 PM, Martin Wilck wrote: > Sparse emits errors about ilog2() in array indices because of the use of > __ilog2_32() and __ilog2_64(), If sparse warns about it, then presumably gcc with -Wvla warns about it too? And if thats the case, then

Re: [PATCHv3] tcmu: allow userspace to reset netlink

On 2018/4/18 0:40, Mike Christie wrote: Nick, Ignore this v3 too. It will not work for deletion. Yeah, for deletion the vfs will lock the file, so there is no any new access could in, will redesign and make it module wide. On 04/16/2018 07:43 AM, xiu...@redhat.com wrote: From: Xiubo Li

[PATCH v3 3/6] scsi: devinfo: change blist_flag_t to 64bit

Space for SCSI blist flags is gradually running out. Change the type to __u64. And fix a checkpatch complaint about symbolic mode flags in scsi_devinfo.c. Make checkpatch happy by replacing simple_strtoul() with kstrtoull(). Signed-off-by: Martin Wilck ---

[PATCH v3 4/6] scsi: devinfo: warn on undefined blist flags

Warn if a device (or the user) sets blist flags which are unknown or have been removed. This should enable us to reuse freed blist bits in later releases. Signed-off-by: Martin Wilck --- drivers/scsi/Makefile | 2 +- drivers/scsi/scsi_devinfo.c | 6 ++

[PATCH v3 6/6] scsi: devinfo: BLIST_RETRY_ASC_C1 for Fujitsu ETERNUS

On Fujitsu ETERNUS systems, sense code ABORTED COMMAND with ASC/Q C1/01 is used to indicate temporary condition where the storage-internal path to a target is switched from one controller to another. SCSI commands that return with this error code must be retried unconditionally (i.e. without the

[PATCH v3 2/6] scsi: use const_ilog2 for array indices

Use the just introduced const_ilog2() macro to avoid sparse errors. Signed-off-by: Martin Wilck --- drivers/scsi/scsi_debugfs.c | 2 +- drivers/scsi/scsi_sysfs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/scsi_debugfs.c

[PATCH v3 5/6] scsi: devinfo: add BLIST_RETRY_ITF for EMC Symmetrix

EMC Symmetrix returns 'internal target error' for a variety of conditions, most of which will be transient. So we should always retry it, even with failfast set. Otherwise we'd get spurious path flaps with multipath. Signed-off-by: Martin Wilck --- drivers/scsi/scsi_devinfo.c |