Re: v4.16-rc1 + dm-mpath + BFQ

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Il giorno 30 mar 2018, alle ore 18:57, Bart Van Assche <bart.vanassche@xxxxxxx> 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.
> 
> 
> 





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux