Re: [PATCH v7 21/23] block: Avoid that flushing triggers a lockdep complaint

[Bart Van Assche]

On Fri, 2019-02-15 at 10:26 +-0800, Ming Lei wrote:
+AD4 There might be lots of blk+AF8-flush+AF8-queue instance which is allocated
+AD4 for each hctx, then lots of class key slot may be wasted.
+AD4 
+AD4 So I suggest to use one nvmet+AF8-loop+AF8-flush+AF8-lock+AF8-key for this particular issue,
+AD4 something like the following patch:
+AD4 
+AD4 diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c
+AD4 index 4aac1b4a8112..ec4248c12ed9 100644
+AD4 --- a/drivers/nvme/target/loop.c
+AD4 +-+-+- b/drivers/nvme/target/loop.c
+AD4 +AEAAQA -524,7 +-524,9 +AEAAQA static const struct nvme+AF8-ctrl+AF8-ops nvme+AF8-loop+AF8-ctrl+AF8-ops +AD0 +AHs
+AD4  
+AD4  static int nvme+AF8-loop+AF8-create+AF8-io+AF8-queues(struct nvme+AF8-loop+AF8-ctrl +ACo-ctrl)
+AD4  +AHs
+AD4 -	int ret+ADs
+AD4 +-	static struct lock+AF8-class+AF8-key  nvme+AF8-loop+AF8-flush+AF8-lock+AF8-key+ADs
+AD4 +-	int ret, i+ADs
+AD4 +-	struct blk+AF8-mq+AF8-hw+AF8-ctx +ACo-hctx+ADs
+AD4  
+AD4  	ret +AD0 nvme+AF8-loop+AF8-init+AF8-io+AF8-queues(ctrl)+ADs
+AD4  	if (ret)
+AD4 +AEAAQA -553,6 +-555,10 +AEAAQA static int nvme+AF8-loop+AF8-create+AF8-io+AF8-queues(struct nvme+AF8-loop+AF8-ctrl +ACo-ctrl)
+AD4  		goto out+AF8-free+AF8-tagset+ADs
+AD4  	+AH0
+AD4  
+AD4 +-	queue+AF8-for+AF8-each+AF8-hw+AF8-ctx(ctrl-+AD4-ctrl.connect+AF8-q, hctx, i)
+AD4 +-		lockdep+AF8-set+AF8-class(+ACY-hctx-+AD4-fq-+AD4-mq+AF8-flush+AF8-lock,
+AD4 +-				+ACY-nvme+AF8-loop+AF8-flush+AF8-lock+AF8-key)+ADs
+AD4 +-
+AD4  	ret +AD0 nvme+AF8-loop+AF8-connect+AF8-io+AF8-queues(ctrl)+ADs
+AD4  	if (ret)
+AD4  		goto out+AF8-cleanup+AF8-connect+AF8-q+ADs

Hi Ming,

Thanks for your feedback.

Are you aware that sizeof(struct lock+AF8-class+AF8-key) is zero if lockdep is
disabled? Does this alleviate your concern?

I'm not enthusiast about your patch. I don't think that block layer users
should touch the lock class key of the flush queue. That's a key that should
be set by the block layer core.

Anyway, let's drop patches 20/23 and 21/23 from this series and let's
continue this discussion on the linux-block mailing list after agreement has
been reached about the +ACI-dynamic lockdep key+ACI approach.

Bart.