| Message ID | 20201112075526.947079-4-ming.lei@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | blk-mq/nvme-loop: use nvme-loop's lock class for addressing lockdep false positive warning | expand |
On 11/11/20 11:55 PM, Ming Lei wrote: > This reverts commit b3c6a59975415bde29cfd76ff1ab008edbf614a9. > > Now we can avoid nvme-loop lockdep warning of 'lockdep possible recursive > locking' by nvme-loop's lock class, no need to apply dynamically > allocated lock class key, so revert commit b3c6a5997541("block: Fix a > lockdep complaint triggered by request queue flushing"). > > This way fixes horrible SCSI probe delay issue on megaraid_sas, and it > is reported the whole probe may take more than half an hour. The code touched by this patch is compiled out with locked disabled so it is not clear to me how this patch could affect a probe delay for megaraid_sas? Has the megaraid_sas probe issue perhaps not been root caused correctly? Thanks, Bart.
On 11/12/20 7:12 AM, Bart Van Assche wrote: > On 11/11/20 11:55 PM, Ming Lei wrote: >> This reverts commit b3c6a59975415bde29cfd76ff1ab008edbf614a9. >> >> Now we can avoid nvme-loop lockdep warning of 'lockdep possible recursive >> locking' by nvme-loop's lock class, no need to apply dynamically >> allocated lock class key, so revert commit b3c6a5997541("block: Fix a >> lockdep complaint triggered by request queue flushing"). >> >> This way fixes horrible SCSI probe delay issue on megaraid_sas, and it >> is reported the whole probe may take more than half an hour. > > The code touched by this patch is compiled out with locked disabled so > it is not clear to me how this patch could affect a probe delay for > megaraid_sas? Has the megaraid_sas probe issue perhaps not been root > caused correctly? (replying to my own email) I found the answer in the descriptions of the previous patches of this series. I think this patch would benefit from a more complete patch description. Thanks, Bart.
On Thu, Nov 12, 2020 at 07:29:13AM -0800, Bart Van Assche wrote: > On 11/12/20 7:12 AM, Bart Van Assche wrote: > > On 11/11/20 11:55 PM, Ming Lei wrote: > >> This reverts commit b3c6a59975415bde29cfd76ff1ab008edbf614a9. > >> > >> Now we can avoid nvme-loop lockdep warning of 'lockdep possible recursive > >> locking' by nvme-loop's lock class, no need to apply dynamically > >> allocated lock class key, so revert commit b3c6a5997541("block: Fix a > >> lockdep complaint triggered by request queue flushing"). > >> > >> This way fixes horrible SCSI probe delay issue on megaraid_sas, and it > >> is reported the whole probe may take more than half an hour. > > > > The code touched by this patch is compiled out with locked disabled so > > it is not clear to me how this patch could affect a probe delay for > > megaraid_sas? Has the megaraid_sas probe issue perhaps not been root > > caused correctly? > > (replying to my own email) > > I found the answer in the descriptions of the previous patches of this > series. I think this patch would benefit from a more complete patch > description. Hello Bart, OK, I can add more words to this commit log. Thanks, Ming
diff --git a/block/blk-flush.c b/block/blk-flush.c index 657743524e15..c64f049226f6 100644 --- a/block/blk-flush.c +++ b/block/blk-flush.c @@ -69,7 +69,6 @@ #include <linux/blkdev.h> #include <linux/gfp.h> #include <linux/blk-mq.h> -#include <linux/lockdep.h> #include "blk.h" #include "blk-mq.h" @@ -469,9 +468,6 @@ struct blk_flush_queue *blk_alloc_flush_queue(int node, int cmd_size, INIT_LIST_HEAD(&fq->flush_queue[1]); INIT_LIST_HEAD(&fq->flush_data_in_flight); - lockdep_register_key(&fq->key); - lockdep_set_class(&fq->mq_flush_lock, &fq->key); - return fq; fail_rq: @@ -486,7 +482,6 @@ void blk_free_flush_queue(struct blk_flush_queue *fq) if (!fq) return; - lockdep_unregister_key(&fq->key); kfree(fq->flush_rq); kfree(fq); } diff --git a/block/blk.h b/block/blk.h index dfab98465db9..806fd6537295 100644 --- a/block/blk.h +++ b/block/blk.h @@ -25,7 +25,6 @@ struct blk_flush_queue { struct list_head flush_data_in_flight; struct request *flush_rq; - struct lock_class_key key; spinlock_t mq_flush_lock; };
This reverts commit b3c6a59975415bde29cfd76ff1ab008edbf614a9. Now we can avoid nvme-loop lockdep warning of 'lockdep possible recursive locking' by nvme-loop's lock class, no need to apply dynamically allocated lock class key, so revert commit b3c6a5997541("block: Fix a lockdep complaint triggered by request queue flushing"). This way fixes horrible SCSI probe delay issue on megaraid_sas, and it is reported the whole probe may take more than half an hour. 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> --- block/blk-flush.c | 5 ----- block/blk.h | 1 - 2 files changed, 6 deletions(-)