diff options
| author | Ming Lei <ming.lei@redhat.com> | 2020-12-03 09:26:36 +0800 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2020-12-07 20:30:19 -0700 |
| commit | fb01a2932e81a1fb2273f87ff92dc8172b8880ee (patch) | |
| tree | 3b8f82bc210b1b8d5a638e8ea194ec3ed634b63a /drivers/nvme/target/loop.c | |
| parent | cc29e1bf0d63f728a5bd60ef22638bbf77369552 (diff) | |
blk-mq: add new API of blk_mq_hctx_set_fq_lock_class
flush_end_io() may be called recursively from some driver, such as
nvme-loop, so lockdep may complain 'possible recursive locking'.
Commit b3c6a5997541("block: Fix a lockdep complaint triggered by
request queue flushing") tried to address this issue by assigning
dynamically allocated per-flush-queue lock class. This solution
adds synchronize_rcu() for each hctx's release handler, and causes
horrible SCSI MQ probe delay(more than half an hour on megaraid sas).
Add new API of blk_mq_hctx_set_fq_lock_class() for these drivers, so
we just need to use driver specific lock class for avoiding the
lockdep warning of 'possible recursive locking'.
Tested-by: Kashyap Desai <kashyap.desai@broadcom.com>
Reported-by: Qian Cai <cai@redhat.com>
Cc: Sumit Saxena <sumit.saxena@broadcom.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Kashyap Desai <kashyap.desai@broadcom.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/nvme/target/loop.c')
0 files changed, 0 insertions, 0 deletions