> Il giorno 30 mar 2018, alle ore 18:57, Bart Van Assche > <bart.vanass...@wdc.com> ha scritto: > > On Fri, 2018-03-30 at 10:23 +0200, Paolo Valente wrote: >> Still 4.16-rc1, being that the version for which you reported this >> issue in the first place. > > A vanilla v4.16-rc1 kernel is not sufficient to run the srp-test software > since RDMA/CM support for the SRP target driver is missing from that kernel. > That's why I asked you to use the for-next branch from my github repository > in a previous e-mail.
Yep, that's the branch/top commit I used (as you suggested): 190943ce1824 [bvanassche/for-next] scsi: mpt3sas: fix oops in error handlers after shutdown/unload with bvanassche https://github.com/bvanassche/linux.git The kernel in that branch presents itself as 4.16-rc1, but, as you point out, it should contain the needed support. > Anyway, since the necessary patches are now in > linux-next, the srp-test software can also be run against linux-next. Here > are the results that I obtained with label next-20180329 and the kernel > config attached to your previous e-mail: > > # while ./srp-test/run_tests -c -d -r 10 -e bfq; do :; done > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000200 > PGD 0 P4D 0 > Oops: 0002 [#1] SMP PTI > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.0.0-prebuilt.qemu-project.org 04/01/2014 > RIP: 0010:rb_erase+0x284/0x380 > Call Trace: > <IRQ> > elv_rb_del+0x24/0x30 > bfq_remove_request+0x9a/0x2e0 [bfq] > ? rcu_read_lock_sched_held+0x64/0x70 > ? update_load_avg+0x72b/0x760 > bfq_finish_requeue_request+0x2e1/0x3b0 [bfq] > ? __lock_is_held+0x5a/0xa0 > blk_mq_free_request+0x5f/0x1a0 > blk_put_request+0x23/0x60 > multipath_release_clone+0xe/0x10 > dm_softirq_done+0xe3/0x270 > __blk_mq_complete_request_remote+0x18/0x20 > flush_smp_call_function_queue+0xa1/0x150 > generic_smp_call_function_single_interrupt+0x13/0x30 > smp_call_function_single_interrupt+0x4d/0x220 > call_function_single_interrupt+0xf/0x20 > </IRQ> > This new trace just confirms my suspects. Looking forward to some feedback from Mike or Jens. Otherwise I'll try to look into it myself, although I don't think I am the right person to suggest the best cure for this cloning issue. Thanks, Paolo > Bart. > > >
