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 --git a/tests/scsi/004 b
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]
[ 38.2758
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:
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 Norton
HRB 21284 (AG N
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 att
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
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 wrote:
I just ran into thi
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, A
>On Mon, 2018-04-16 at 20:27 +, Bean Huo (beanhuo) wrote:
>> By the way, these patches are not to add new feature, they are just to
>> add print tag along with the other exist printed request parameters.
>
>Are you aware that there are two tag fields in struct request, namely "tag"
>and "intern
Thank you for the reply.
> On Wed, Mar 28, 2018 at 11:25:34AM +, Janek Kotas wrote:
>> This patch adds a device tree platform
>> driver description for Cadence UFS Controller.
>
> You have exactly the same subject for both patches. Don't do that. For
> bindings, the preferred subject prefix
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
---
arch/arm64/configs/defconfig | 8
1 file changed, 8 inserti
add ufs node document for Hisilicon.
Signed-off-by: Li Wei
---
Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 29 ++
.../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +---
2 files changed, 36 insertions(+), 3 deletions(-)
create mode 100644 Documentation/dev
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: defco
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 a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf613761e7
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 ec3eb8e33a3a..e9013d4
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 +
drivers/scsi/ufs/Makefile | 1 +
drivers/scsi/ufs/ufs-hisi.c | 621
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.
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 w
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 caugh
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 inst
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 have a
specific place to watch
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
> this either. The bfdq is
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 has crashed or force
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:
> 3902
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
>> 3900if (rq) {
>> 3901inc_
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:
> 3902
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] [] device_release+0x32/0xa0
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 function bfq_dispatch_requ
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 decimal:
>>
>> (gdb) disass bfq_dispatch_reque
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 block/bfq-iosched.c:3902, just with KASAN
>>> removed. 0x99 is 153 dec
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.
#define RQ_BFQQ(rq)
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-mq.c
index 0dc9e341c2a
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 for me:
>
> diff --git a
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 the sense buffer address
slowly start increme
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
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 state that can leak
>>> in t
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 possible
there is some kind of uninitialize
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 things!
Thanks for the pointers, and thank you O
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 Hellwig
> Cc: Hannes Reinecke
> ---
> drivers/scsi/
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
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 blkdev_report_zones()
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] assignments made in a few places -- is it poss
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 (rq->elv.priv[1]) a
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
>>> caused BFQ to thin
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 PM, Kees Cook wrote:
>> I see
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 a/
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 Cook wrote:
>> On Tue, Apr 17, 201
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 pare
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 of
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 b/drivers/scsi/scsi_debugfs.c
ind
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
---
drivers/scsi/scsi_devinfo.c | 18 +
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 | 3 ++-
drivers/sc
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 ++
include/scsi/scsi_devinfo.h | 2
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 "m
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 __builtin_constant_p() and a t
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
Th
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 popula
57 matches
Mail list logo
