summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc
diff options
context:
space:
mode:
authorPalla Raghunath <raghunathpalla.0209@gmail.com>2026-09-30 07:26:47 +0100
committerKeith Busch <kbusch@kernel.org>2026-10-03 01:55:29 -0700
commitb3ce7572130f7bdc71581d798df3fbfc3b64e7a5 (patch)
tree2fa42c3aeba64012e76365e4be7627752733f9dd /tools/lib/python/kdoc
parent564e46d9f6e87912effa03f123d37a511d520f09 (diff)
downloadlinux-next-b3ce7572130f7bdc71581d798df3fbfc3b64e7a5.tar.gz
linux-next-b3ce7572130f7bdc71581d798df3fbfc3b64e7a5.zip
nvme-multipath: revalidate head zones after unfreezing the head queue
When a namespace on a multipath controller is updated, nvme_update_ns_info() freezes the head disk queue, commits the new limits, and then calls nvme_mpath_revalidate_zones() before it unfreezes the queue again. That is the wrong way round for blk_revalidate_disk_zones(). It starts a limits update, which takes q->limits_lock, and it freezes the queue itself while updating the zone resources. The block layer takes limits_lock before freezing the queue, never the other way around, so calling it with the head queue already frozen reverses that order. syzbot has hit this twice. One report goes through q->limits_lock. The other one is on linux-next, where blk_revalidate_disk_zones() also takes disk->zone_revalidate_mutex and holds it across alloc_workqueue() the first time a disk's zone resources are set up. Lockdep then sees: q_usage_counter(io) (frozen head queue, nvme_update_ns_info()) --> &disk->zone_revalidate_mutex --> wq_pool_mutex --> fs_reclaim --> q_usage_counter(io) WARNING: possible circular locking dependency detected kworker/u8:10/3352 is trying to acquire lock: (&disk->zone_revalidate_mutex){+.+.}-{4:4}, at: blk_revalidate_disk_zones+0x1c5/0x1650 but task is already holding lock: (&q->q_usage_counter(io)#75){++++}-{0:0}, at: nvme_update_ns_info+0x3ac/0x1200 ... blk_revalidate_disk_zones+0x1c5/0x1650 block/blk-zoned.c:2560 nvme_mpath_revalidate_zones+0x106/0x1c0 drivers/nvme/host/multipath.c:301 nvme_update_ns_info+0x984/0x1200 drivers/nvme/host/core.c:2620 The rest of the driver already does this correctly: nvme_update_ns_info_block() unfreezes ns->disk->queue before calling blk_revalidate_disk_zones(), and nvme_mpath_set_live() revalidates the head zones without freezing the queue. Do the same here, and only revalidate the head zones once the queue is unfrozen and the limits update has succeeded. Fixes: 224041412693 ("nvme-multipath: revalidate zones for namespace heads") Reported-by: syzbot+b0910be96b7c31314822@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b0910be96b7c31314822 Reported-by: syzbot+2e02ccadb3c5522a5c59@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=2e02ccadb3c5522a5c59 Link: https://lore.kernel.org/all/2bfc96f2-7d0d-47e0-936e-8810abb31a9f@acm.org/ Cc: Shuah Khan <shuah@kernel.org> Cc: Brigham Campbell <me@brighamcampbell.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Yao Sang <sangyao@kylinos.cn> Tested-by: Yao Sang <sangyao@kylinos.cn> Signed-off-by: Palla Raghunath <raghunathpalla.0209@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc')
0 files changed, 0 insertions, 0 deletions