Files
Chao Shi d6998ddd50 block: skip sync_blockdev() on surprise removal in bdev_mark_dead()
commit 49f06cff50 upstream.

bdev_mark_dead()'s @surprise == true means the device is already gone.
The filesystem callback fs_bdev_mark_dead() honours this and skips
sync_filesystem(), but the bare block device path (no ->mark_dead op)
lost its !surprise guard when the holder ->mark_dead callback was wired
up (see Fixes), and now calls sync_blockdev() unconditionally, which can
hang forever waiting on writeback that can no longer complete.

syzkaller hit this via nvme_reset_work()'s "I/O queues lost" path:
nvme_mark_namespaces_dead() -> blk_mark_disk_dead() ->
bdev_mark_dead(bdev, true) -> sync_blockdev() blocks in
folio_wait_writeback(), wedging the reset worker and every task waiting
on it.

Skip the sync on surprise removal, matching fs_bdev_mark_dead();
invalidate_bdev() still runs. Orderly removal (surprise == false) is
unchanged.

Found by FuzzNvme.

Fixes: d8530de5a6 ("block: call into the file system for bdev_mark_dead")
Acked-by: Sungwoo Kim <iam@sung-woo.kim>
Acked-by: Dave Tian <daveti@purdue.edu>
Acked-by: Weidong Zhu <weizhu@fiu.edu>
Signed-off-by: Chao Shi <coshi036@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260522220025.1770388-1-coshi036@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
[ adjusted for 6.6.y: bdev_mark_dead() there still unlocks bd_holder_lock
  after the if/else and the else arm is a bare sync_blockdev(), so the
  !surprise guard is added as "else if (!surprise)" instead of inside the
  mainline else block. ]
Signed-off-by: Chao Shi <coshi036@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-24 16:02:56 +02:00
..
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…