diff options
| author | Heinz Mauelshagen <heinzm@redhat.com> | 2026-01-14 18:52:21 +0100 |
|---|---|---|
| committer | Yu Kuai <yukuai@fnnas.com> | 2026-01-26 13:46:40 +0800 |
| commit | cefcb9297fbdb6d94b61787b4f8d84f55b741470 (patch) | |
| tree | 88b57971306367c5ad2827236f57e917c199a3f9 /rust/alloc/collections/git@git.tavy.me:linux.git | |
| parent | f150e753cb8dd756085f46e86f2c35ce472e0a3c (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
