On 2019-01-10 6:22 p.m., Bart Van Assche wrote:
Hi Doug,
Have you ever tried to run the libiscsi conformance tests against
the scsi_debug driver? I tried the following:
modprobe scsi_debug delay=0 max_luns=3
dev=$(for f in
/sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/[0-9]*/block/*; do
echo $f; break; done)
dev=/dev/$(basename $dev)
libiscsi/test-tool/iscsi-test-cu --dataloss --allow-sanitize "$dev"
That test triggers the following output:
BUG: unable to handle kernel paging request at ffffa8d741235e00
PGD 13b141067 P4D 13b141067 PUD 13b146067 PMD 6fc5a067 PTE 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 4967 Comm: iscsi-test-cu Not tainted 4.18.0-13-generic #14-Ubuntu
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
RIP: 0010:memcpy_erms+0x6/0x10
Since memory corruption errors have been found elsewhere in
lk 5.0-rc1 and a fix looks like it is pending, I will leave this
one alone as I can't replicate it.
Doug Gilbert
Code: ff ff ff 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89
d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00
48 89 f8 48 83 fa 20 72 7e 40 38 fe
Call Trace:
sg_copy_to_buffer+0x12/0x20
fetch_to_dev_buffer+0x4a/0x60 [scsi_debug]
resp_write_same.part.35+0x125/0x190 [scsi_debug]
resp_write_same_16+0x84/0xe0 [scsi_debug]
schedule_resp+0x4b/0x790 [scsi_debug]
scsi_debug_queuecommand+0x218/0x9c0 [scsi_debug]
scsi_dispatch_cmd+0x98/0x230
scsi_queue_rq+0x4dc/0x5b0
blk_mq_dispatch_rq_list+0x93/0x4f0
blk_mq_do_dispatch_ctx+0xcd/0x130
blk_mq_sched_dispatch_requests+0x156/0x190
__blk_mq_run_hw_queue+0x57/0xe0
__blk_mq_delay_run_hw_queue+0x14d/0x160
blk_mq_run_hw_queue+0x5a/0x120
blk_mq_sched_insert_request+0x11d/0x180
blk_execute_rq_nowait+0x6f/0x100
blk_execute_rq+0x50/0xb0
sg_io+0x199/0x410
scsi_cmd_ioctl+0x1b9/0x3f0
scsi_cmd_blk_ioctl+0x51/0x61
sd_ioctl+0xcd/0x1c0
blkdev_ioctl+0x3b8/0x980
block_ioctl+0x3d/0x50
do_vfs_ioctl+0xa8/0x620
ksys_ioctl+0x67/0x90
__x64_sys_ioctl+0x1a/0x20
do_syscall_64+0x5a/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Is this reproducible on your test setup?
Thanks,
Bart.
