On Thu, 2019-01-24 at 01:13 -0500, Douglas Gilbert wrote: +AD4 +AD4 I can replicate this crash easily. I also noticed that this crash only occurs if +AD4 +AD4 the scsi+AF8-debug driver is loaded with fake+AF8-rw+AD0-0. It does not occur with fake+AF8-rw+AD0-1. +AD4 +AD4 It seems like the following code in resp+AF8-write+AF8-same() assumes that fake+AF8-storep +ACEAPQ NULL? +AD4 +AD4 +AD4 +AD4 /+ACo if ndob then zero 1 logical block, else fetch 1 logical block +ACo-/ +AD4 +AD4 if (ndob) +AHs +AD4 +AD4 memset(fake+AF8-storep +- lba+AF8-off, 0, sdebug+AF8-sector+AF8-size)+ADs +AD4 +AD4 ret +AD0 0+ADs +AD4 +AD4 +AH0 else +AD4 +AD4 ret +AD0 fetch+AF8-to+AF8-dev+AF8-buffer(scp, fake+AF8-storep +- lba+AF8-off, +AD4 +AD4 sdebug+AF8-sector+AF8-size)+ADs +AD4 +AD4 It is table driven. It shouldn't call that function if FF+AF8-MEDIA+AF8-IO is part of +AD4 that command's flag and fake+AF8-storep is NULL. Both WS10 and WS16 have that flag. +AD4 +AD4 But there is a problem if virtual+AF8-gb +AD4 0 . +AD4 +AD4 Could you try the attached patch, it should wrap cleanly in the virtual+AF8-gb +AD4 0 +AD4 case. Hi Doug, With this patch applied the libiscsi tests no longer cause the scsi+AF8-debug to trigger a kernel oops. Thanks+ACE Bart.
