On 4/3/25 4:24 PM, Ming Lei wrote: > ->elevator_lock depends on queue freeze lock, see block/blk-sysfs.c. > > queue freeze lock depends on fs_reclaim. > > So don't grab elevator lock during queue initialization which needs to > call kmalloc(GFP_KERNEL), and we can cut the dependency between > ->elevator_lock and fs_reclaim, then the lockdep warning can be killed. > > This way is safe because elevator setting isn't ready to run during > queue initialization. > > There isn't such issue in __blk_mq_update_nr_hw_queues() because > memalloc_noio_save() is called before acquiring elevator lock. > > Fixes the following lockdep warning: > > https://lore.kernel.org/linux-block/67e6b425.050a0220.2f068f.007b.GAE@xxxxxxxxxx/ > > Reported-by: syzbot+4c7e0f9b94ad65811efb@xxxxxxxxxxxxxxxxxxxxxxxxx > Cc: Nilay Shroff <nilay@xxxxxxxxxxxxx> > Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx> > --- > block/blk-mq.c | 24 +++++++++++++++++------- > 1 file changed, 17 insertions(+), 7 deletions(-) > I think you earlier posted this same patch here: https://lore.kernel.org/linux-block/Z-dUCLvf06SfTOHy@fedora/ I tested that earlier patch and got into another lockdep splat as reported here: https://lore.kernel.org/linux-block/462d4e8a-dd95-48fe-b9fe-a558057f9595@xxxxxxxxxxxxx/ I don't know why we think your earlier fix which cut dependency between ->elevator_lock and ->freeze_lock doesn't work. But anyways, my view is that we've got into these lock chains from two different code paths: path1: elevator_lock -> fs_reclaim (GFP_KERNEL) -> freeze_lock path2: freeze_lock(memalloc_noio) -> elevator_lock -> fs_reclaim (this becomes NOP in this case due to memalloc_noio) As you could see above, we've got into circular dependency between ->elevator_lock and ->freeze_lock. I thought with your earlier patch we were able to cut that dependency using blk_mq_enter_no_io and blk_mq_exit_no_io. But I'm not sure why we think that won't work? Thanks, --Nilay
