On Thu, Feb 06, 2025 at 06:52:36PM +0530, Nilay Shroff wrote: > Yeah I tested with a multi namespace NVMe disk and lockdep didn't > complain. Agreed we need to hold up q->sysfs_lock for multiple > request queues at the same time and that may not be elegant, but > looking at the mess in __blk_mq_update_nr_hw_queues we may not > have other choice which could help correct the lock order. Odd, as it's usually very unhappy about nesting locks of the same kind unless specifically annotated. > Yes this is probably a good idea, that instead of using q->sysfs_lock > we may depend on q->tag_set->tag_list_lock here for sched/elevator updates > as a fact that __blk_mq_update_nr_hw_queues already runs with tag_list_lock > held. Yes. > But then it also requires using the same tag_list_lock instead of > current sysfs_lock while we update the scheduler from sysfs. But that's > a trivial change. Yes. I think it's a good idea, but maybe wait a bit to see if Jens or Ming also have opinions on this before starting the work.
