On Tue, 2019-01-22 at 23:49 -0500, Douglas Gilbert wrote: +AD4 On 2019-01-22 7:56 p.m., Bart Van Assche wrote: +AD4 +AD4 On Tue, 2019-01-22 at 18:30 -0500, Douglas Gilbert wrote: +AD4 +AD4 +AD4 This patchset needs something like the following if UAS (USB Attached +AD4 +AD4 +AD4 SCSI) is configured in your kernel. +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 Beware of tabs/spaces/line+AF8-wraps as this is a cut and paste: +AD4 +AD4 +AD4 +AD4 +AD4 +AD4 diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c +AD4 +AD4 +AD4 index 36742e8e7edc..24f3f95917a5 100644 +AD4 +AD4 +AD4 --- a/drivers/usb/storage/uas.c +AD4 +AD4 +AD4 +-+-+- b/drivers/usb/storage/uas.c +AD4 +AD4 +AD4 +AEAAQA -401,9 +-401,9 +AEAAQA static void uas+AF8-data+AF8-cmplt(struct urb +ACo-urb) +AD4 +AD4 +AD4 if (status +ACEAPQ -ENOENT +ACYAJg status +ACEAPQ -ECONNRESET +ACYAJg status +ACEAPQ +AD4 +AD4 +AD4 -ESHUTDOWN) +AD4 +AD4 +AD4 uas+AF8-log+AF8-cmd+AF8-state(cmnd, +ACI-data cmplt err+ACI, status)+ADs +AD4 +AD4 +AD4 /+ACo error: no data transfered +ACo-/ +AD4 +AD4 +AD4 - sdb-+AD4-resid +AD0 sdb-+AD4-length+ADs +AD4 +AD4 +AD4 +- scsi+AF8-in+AF8-set+AF8-resid(cmnd, sdb-+AD4-length)+ADs +AD4 +AD4 +AD4 +AH0 else +AHs +AD4 +AD4 +AD4 - sdb-+AD4-resid +AD0 sdb-+AD4-length - urb-+AD4-actual+AF8-length+ADs +AD4 +AD4 +AD4 +- scsi+AF8-in+AF8-set+AF8-resid(cmnd, sdb-+AD4-length - urb-+AD4-actual+AF8-length)+ADs +AD4 +AD4 +AD4 +AH0 +AD4 +AD4 +AD4 uas+AF8-try+AF8-complete(cmnd, +AF8AXw-func+AF8AXw)+ADs +AD4 +AD4 +AD4 out: +AD4 +AD4 +AD4 +AD4 Thanks Doug+ACE I will fold a slightly modified version of this patch in. BTW, +AD4 +AD4 does this mean that you have been able to test this patch series? +AD4 +AD4 Yes, but I didn't get far. With my sg v4 driver, scsi+AF8-debug and my sg+AF8-tst+AF8-bidi +AD4 utility and this patchset after a short while I get a NULL pointer dereference +AD4 in scsi+AF8-mq+AF8-prep+AF8-fn() inside the bidi conditional, probably the memset(). +AD4 +AD4 RIP ---+AD4 0x2ce7 +AD4 +AD4 .... +AD4 if (blk+AF8-bidi+AF8-rq(req)) +AHs +AD4 2c9a: 49 8b 85 20 01 00 00 mov 0x120(+ACU-r13),+ACU-rax +AD4 2ca1: 48 85 c0 test +ACU-rax,+ACU-rax +AD4 2ca4: 74 60 je 2d06 +ADw-scsi+AF8-queue+AF8-rq+-0x436+AD4 +AD4 memset(+ACY-scsi+AF8-in+AF8-cmd(cmd)-+AD4-sdb, 0, +AD4 2ca6: 48 c7 80 28 02 00 00 movq +ACQ-0x0,0x228(+ACU-rax) +AD4 2cad: 00 00 00 00 +AD4 2cb1: 48 c7 80 30 02 00 00 movq +ACQ-0x0,0x230(+ACU-rax) +AD4 2cb8: 00 00 00 00 +AD4 2cbc: 48 c7 80 38 02 00 00 movq +ACQ-0x0,0x238(+ACU-rax) +AD4 2cc3: 00 00 00 00 +AD4 2cc7: 49 8b 85 60 02 00 00 mov 0x260(+ACU-r13),+ACU-rax +AD4 2cce: 48 8b 90 20 01 00 00 mov 0x120(+ACU-rax),+ACU-rdx +AD4 2cd5: 48 8d 82 28 01 00 00 lea 0x128(+ACU-rdx),+ACU-rax +AD4 2cdc: 48 85 d2 test +ACU-rdx,+ACU-rdx +AD4 2cdf: 49 0f 44 c6 cmove +ACU-r14,+ACU-rax +AD4 cmd-+AD4-device-+AD4-host-+AD4-hostt-+AD4-cmd+AF8-size+ADs +AD4 2ce3: 48 8b 50 38 mov 0x38(+ACU-rax),+ACU-rdx +AD4 2ce7: 48 8b 12 mov (+ACU-rdx),+ACU-rdx +ADwAPQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9 +AD4 2cea: 48 8b 92 98 00 00 00 mov 0x98(+ACU-rdx),+ACU-rdx +AD4 2cf1: 8b 92 30 01 00 00 mov 0x130(+ACU-rdx),+ACU-edx +AD4 cmd-+AD4-sdb.table.sgl +AD0 (void +ACo)cmd +- sizeof(struct scsi+AF8-cmnd) +- +AD4 2cf7: 48 8d 94 10 b0 01 00 lea 0x1b0(+ACU-rax,+ACU-rdx,1),+ACU-rdx +AD4 2cfe: 00 +AD4 2cff: 48 89 90 00 01 00 00 mov +ACU-rdx,0x100(+ACU-rax) +AD4 blk+AF8-mq+AF8-start+AF8-request(req) +AD4 ..... +AD4 +AD4 It might not be your patchset, but the location does look suspicious. Hi Doug, I think this means that the scsi+AF8-in+AF8-cmd(cmd)-+AD4-device pointer is NULL. I will address this in the next version of this patch series. Thanks, Bart.
