kernel/git/stable/linux-stable.git/drivers/md/raid5.c, branch master

md/raid5: split reshape bios before bitmap accounting

2026-08-07T06:43:36+00:00

RAID5 maps array sectors through different geometries before and after the reshape position. During llbitmap reshape, md core cannot account one bio against both geometries as a single bitmap range, because the old and new bitmap mappings can cover different chunks. Split bios that cross reshape_position before md_account_bio(), so the bitmap only sees ranges that belong to one side of the reshape boundary. mddev_bio_split_at_reshape_offset() uses bio_submit_split_bioset(), which submits the remainder immediately and returns the front split bio. If that front bio later has to wait for reshape, md_handle_request() must not retry the original bio pointer, because after the split that pointer is the already-submitted remainder. Track whether the split happened, clear the temporary BLK_STS_RESOURCE status after the internal clone completion, and resubmit the front bio directly after the reshape wait. Keep the old return-false retry path for unsplit bios, where md_handle_request() still owns the same bio. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-30-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid5: wire llbitmap reshape lifecycle

2026-08-07T06:43:36+00:00

Prepare llbitmap before RAID5 reshape starts, checkpoint the bitmap before advancing reshape_position, and finish the llbitmap geometry update when reshape completes. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-29-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid5: reject llbitmap reshape when md chunk shrinks

2026-08-07T06:43:36+00:00

llbitmap reshape keeps one live bitmap and cannot safely make an existing bitmap bit cover a smaller data range. The llbitmap chunksize itself will not shrink when mddev->chunk_sectors stays the same or grows. However, shrinking mddev->chunk_sectors shrinks sectors_per_chunk used by raid5_bitmap_sector_map(). That can shrink the effective data range covered by each bit across the old and new RAID5 geometry. Reject that reshape while llbitmap is active. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-28-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid5: add exact old and new llbitmap mapping helpers

2026-08-07T06:43:36+00:00

Teach RAID5 to export exact old and new llbitmap mappings and the corresponding sync and array sizes for reshape-aware bitmap users. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-27-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid5: round bitmap stripes with sector division

2026-08-07T06:43:33+00:00

raid5_bitmap_sector_map() aligns the array range to full RAID5 stripe widths before converting it to component sectors. That width is chunk_sectors multiplied by the number of data disks, and it is not always a power of two. Reproduce with a 4-disk RAID5, 1024-sector chunks, and three data disks. The full-stripe width is 3072 sectors. For a one-sector write at array sector 3072, correct rounding gives array range [3072, 6144), which maps to component range [1024, 2048). The old round_down()/round_up() logic instead gives [1024, 4096), which maps to [0, 1024). Use sector_div() based arithmetic so the rounded range is aligned to the actual RAID5 stripe width. The deterministic mapper test now reports the fixed component range as [1024, 2048), while the old mask-based range was [0, 1024). Fixes: 9c89f604476c ("md/raid5: implement pers->bitmap_sector()") Reported-by: Mykola Marzhan Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-6-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid5: reject zero-sector reshape chunks

2026-08-07T06:43:33+00:00

Sashiko reported that RAID5 can accept a reshape chunk size that becomes zero sectors. chunk_size_store() stores the sysfs byte value as n >> 9, so writing a value below 512 bytes sets mddev->new_chunk_sectors to zero. RAID5 then accepted that pending reshape geometry and raid5_start_reshape() installed it into conf->chunk_sectors, letting reshape code divide by zero. Reject zero-sector chunks both in check_reshape(), where normal sysfs requests are validated, and in raid5_start_reshape(), so assembly/resume paths also cannot install zero chunk geometry. Test script: in QEMU, create a plain three-disk RAID5 array with 64K chunks, write/read back a small pattern, write 1 to /sys/block/md0/md/chunk_size, add a fourth disk, and run mdadm --grow --raid-devices=4 --backup-file=... . The script scans dmesg for divide error/Oops/KASAN signatures. Bad kernel, eb29914412c3: echo 1 > /sys/block/md0/md/chunk_size mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/root/md0-grow.bak Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: raid5_get_active_stripe+0x863/0xc10 Call Trace: raid5_sync_request md_do_sync md_thread Kernel panic - not syncing: Fatal exception Fixed kernel: echo 1 > /sys/block/md0/md/chunk_size bash: echo: write error: Invalid argument chunk_write_rc=1 grow_rc=skipped RESULT: REJECTED_ZERO_CHUNK_NO_OOPS Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-5-yukuai@kernel.org Signed-off-by: Yu Kuai

md: scope memalloc_noio to allocation critical sections

2026-07-31T05:22:37+00:00

Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token. Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array. A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write. Link: https://github.com/chencheng-fnnas/reproducer/blob/main/repro-md-noio-token-leak.sh Fixes: 78f57ef9d50a ("md: use memalloc scope APIs in mddev_suspend()/mddev_resume()") Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260718084218.417895-1-chencheng@fnnas.com Signed-off-by: Yu Kuai

md/raid5: complete discard bios while reshape is active

2026-07-31T04:34:44+00:00

make_discard_request() returns without completing the bio when reshape is in progress. Discard callers block in submit_bio_wait() waiting for a completion that never arrives. The caller hangs in uninterruptible sleep, and this does not resolve when reshape finishes. Complete the bio with BLK_STS_AGAIN so userspace can retry after reshape, consistent with the existing policy of not processing discard during reshape. Tested on a loop-backed RAID5 array during mdadm --grow: without this patch, blkdiscard hangs in bio_await() and remains in uninterruptible sleep after md reports "reshape done"; with this patch it returns -EAGAIN instead. Signed-off-by: Genjian Zhang Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260711161326.962336-1-zhanggenjian@126.com Signed-off-by: Yu Kuai

md: remove REQ_NOWAIT support from raid1/10/456

2026-07-30T10:46:32+00:00

REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data. Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support. Fixes: bf2c411bb1cf ("md: raid456 add nowait support") Fixes: c9aa889b035f ("md: raid10 add nowait support") Fixes: 5aa705039c4f ("md: raid1 add nowait support") Fixes: f51d46d0e7cb ("md: add support for REQ_NOWAIT") Suggested-by: Yu Kuai Signed-off-by: Abd-Alrhman Masalkhi Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260628142737.1051059-1-abd.masalkhi@gmail.com Signed-off-by: Yu Kuai

md/raid5: protect lockless recovery_offset accesses during reshape

2026-07-30T09:46:21+00:00

During reshape: - reshape_request() advances rdev->recovery_offset for non-In_sync devices locklessly. - analyse_stripe() reads rdev->recovery_offset locklessly to decide: a. use a replacement device to read ? b. a device can already be treated as in-sync for the current stripe ? one possible scenario is: CPU1 CPU2 reshape_request() -> mddev->curr_resync_completed = sector_nr -> if (!mddev->reshape_backwards) -> rdev->recovery_offset = sector_nr analyse_stripe(sh) -> rdev = conf->disks[i].replacement -> if (rdev->recovery_offset >= sh->sector + stripe_sectors) set_bit(R5_ReadRepl) -> or -> if (sh->sector + stripe_sectors <= rdev->recovery_offset) set_bit(R5_Insync) And it could be: - reading from a replacement before it is recovered far enough; or - treating a not-yet-recovered device as in-sync for the current stripe. Fixes: db0505d32066 ("md: be cautious about using ->curr_resync_completed for ->recovery_offset") The race report: ================================================================== BUG: KCSAN: data-race in ops_run_io / reshape_request write to 0xffff8bdee168b270 of 8 bytes by task 1704 on cpu 10: reshape_request+0x1292/0x17b0 raid5_sync_request+0x815/0xa00 md_do_sync.cold+0xf8d/0x1516 [......] read to 0xffff8bdee168b270 of 8 bytes by task 1696 on cpu 9: ops_run_io+0xc25/0x1960 handle_stripe+0x2273/0x4570 handle_active_stripes.isra.0+0x6e0/0xa50 raid5d+0x7d5/0xb90 [......] value changed: 0x0000000000091a00 -> 0x0000000000091b00 ================================================================== Signed-off-by: Chen Cheng Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260627102519.136940-1-chencheng@fnnas.com Signed-off-by: Yu Kuai