summaryrefslogtreecommitdiff
path: root/rust/kernel/gpu/git@git.tavy.me:linux-stable.git
diff options
context:
space:
mode:
authorFengWei Shih <dannyshih@synology.com>2026-03-19 13:33:51 +0800
committerYu Kuai <yukuai@fnnas.com>2026-03-22 09:57:33 +0800
commit52e4324935be917f8f3267354b3cc06bb8ffcec1 (patch)
tree1caa3908744b5eb02d7c7f0d87df9fd84aa7f585 /rust/kernel/gpu/git@git.tavy.me:linux-stable.git
parentef4ca3d4bf09716cff9ba00eb0351deadc8417ab (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