diff options
| author | FengWei Shih <dannyshih@synology.com> | 2026-03-19 13:33:51 +0800 |
|---|---|---|
| committer | Yu Kuai <yukuai@fnnas.com> | 2026-03-22 09:57:33 +0800 |
| commit | 52e4324935be917f8f3267354b3cc06bb8ffcec1 (patch) | |
| tree | 1caa3908744b5eb02d7c7f0d87df9fd84aa7f585 /rust/kernel/gpu/git@git.tavy.me:linux-stable.git | |
| parent | ef4ca3d4bf09716cff9ba00eb0351deadc8417ab (diff) | |
md/raid5: skip 2-failure compute when other disk is R5_LOCKED
When skip_copy is enabled on a doubly-degraded RAID6, a device that is
being written to will be in R5_LOCKED state with R5_UPTODATE cleared.
If a new read triggers fetch_block() while the write is still in
flight, the 2-failure compute path may select this locked device as a
compute target because it is not R5_UPTODATE.
Because skip_copy makes the device page point directly to the bio page,
reconstructing data into it might be risky. Also, since the compute
marks the device R5_UPTODATE, it triggers WARN_ON in ops_run_io()
which checks that R5_SkipCopy and R5_UPTODATE are not both set.
This can be reproduced by running small-range concurrent read/write on
a doubly-degraded RAID6 with skip_copy enabled, for example:
mdadm -C /dev/md0 -l6 -n6 -R -f /dev/loop[0-3] missing missing
echo 1 > /sys/block/md0/md/skip_copy
fio --filename=/dev/md0 --rw=randrw --bs=4k --numjobs=8 \
--iodepth=32 --size=4M --runtime=30 --time_based --direct=1
Fix by checking R5_LOCKED before proceeding with the compute. The
compute will be retried once the lock is cleared on IO completion.
Signed-off-by: FengWei Shih <dannyshih@synology.com>
Reviewed-by: Yu Kuai <yukuai@fnnas.com>
Link: https://lore.kernel.org/linux-raid/20260319053351.3676794-1-dannyshih@synology.com/
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Diffstat (limited to 'rust/kernel/gpu/git@git.tavy.me:linux-stable.git')
0 files changed, 0 insertions, 0 deletions
