On 12/17/19 5:24 PM, Bart Van Assche wrote:
> Avoid that running test nvme/012 from the blktests suite triggers the
> following false positive lockdep complaint:
>
> ============================================
> WARNING: possible recursive locking detected
> 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Not tainted
> --------------------------------------------
> ksoftirqd/1/16 is trying to acquire lock:
> 000000000282032e (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
>
> but task is already holding lock:
> 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock(&(&fq->mq_flush_lock)->rlock);
> lock(&(&fq->mq_flush_lock)->rlock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 1 lock held by ksoftirqd/1/16:
> #0: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0
>
> stack backtrace:
> CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> dump_stack+0x67/0x90
> __lock_acquire.cold.45+0x2b4/0x313
> lock_acquire+0x98/0x160
> _raw_spin_lock_irqsave+0x3b/0x80
> flush_end_io+0x4e/0x1d0
> blk_mq_complete_request+0x76/0x110
> nvmet_req_complete+0x15/0x110 [nvmet]
> nvmet_bio_done+0x27/0x50 [nvmet]
> blk_update_request+0xd7/0x2d0
> blk_mq_end_request+0x1a/0x100
> blk_flush_complete_seq+0xe5/0x350
> flush_end_io+0x12f/0x1d0
> blk_done_softirq+0x9f/0xd0
> __do_softirq+0xca/0x440
> run_ksoftirqd+0x24/0x50
> smpboot_thread_fn+0x113/0x1e0
> kthread+0x121/0x140
> ret_from_fork+0x3a/0x50
Applied, thanks.
--
Jens Axboe
