summaryrefslogtreecommitdiff
path: root/rust/alloc/collections/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorHeinz Mauelshagen <heinzm@redhat.com>2026-01-14 18:52:21 +0100
committerYu Kuai <yukuai@fnnas.com>2026-01-26 13:46:40 +0800
commitcefcb9297fbdb6d94b61787b4f8d84f55b741470 (patch)
tree88b57971306367c5ad2827236f57e917c199a3f9 /rust/alloc/collections/git@git.tavy.me:linux.git
parentf150e753cb8dd756085f46e86f2c35ce472e0a3c (diff)
md raid: fix hang when stopping arrays with metadata through dm-raid
When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions. This occurs when: - A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices) - The top-level RAID device is then removed Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block. Fix: - Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O - Still allow write-intent bitmap flushing when called from dm-raid suspend context This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state. This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above. Link: https://lore.kernel.org/linux-raid/CAM23VxqYrwkhKEBeQrZeZwQudbiNey2_8B_SEOLqug=pXxaFrA@mail.gmail.com Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Yu Kuai <yukuai@fnnas.com>
Diffstat (limited to 'rust/alloc/collections/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions