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

md: skip discard on unsupported member devices

2026-08-07T08:36:32+00:00

blk_stack_limits() uses min_not_zero() when stacking discard limits. Thus an array containing devices with different discard capabilities can expose discard support as long as at least one member has a non-zero discard limit. raid0 and raid10 use md_submit_discard_bio() to submit a discard bio to each member covered by the request. The helper currently also submits bios to members whose max_discard_sectors is zero. The block layer completes these bios with BLK_STS_NOTSUPP, and bio chaining propagates that status to the original discard request. Discard is optional, so skip members which do not support it. Members that do support discard continue to receive their portion of the request. Signed-off-by: Wale Zhang Link: https://patch.msgid.link/20260731074729.1885314-1-wale.zhang.ftd@gmail.com Signed-off-by: Yu Kuai

md: add cond_resched() to md_do_sync()'s skip path

2026-08-07T08:10:39+00:00

When sync_request() reports a skipped region (*skipped == 1), md_do_sync()'s main loop advances the cursor and takes an early continue: j += sectors; ... if (last_check + window > io_sectors || j == max_sectors) continue; If the personality returns a small span per call (raid10 recovery returns only 128 sectors), syncing a large, mostly clean array iterates this branch an enormous number of times without ever yielding the CPU. On a non-preemptive kernel the resync thread then trips the soft-lockup watchdog: watchdog: BUG: soft lockup - CPU#149 stuck for 313s! [mdX_resync] md_bitmap_start_sync+0x6f/0xe0 raid10_sync_request+0x2c9/0x1530 [raid10] md_do_sync+0x810/0x1030 md_thread+0xa7/0x150 Add a cond_resched(). This does not reduce the wasted iterations; the excessive iteration count is a raid10 problem addressed separately. Signed-off-by: Yunye Zhao Link: https://patch.msgid.link/20260723135535.101995-3-yunye.zhao@linux.alibaba.com Signed-off-by: Yu Kuai

md/md-llbitmap: add reshape range mapping helpers

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

Teach llbitmap to choose old versus new geometry during reshape and to encode exact bitmap ranges for the active geometry. This is the mapping groundwork for checkpoint remapping. Range preparation now distinguishes writes from discards. Normal writes must cover every touched bitmap chunk, while discards may only mark fully covered chunks unwritten. Without this distinction, a discard that starts or ends inside a chunk can make live data look unwritten after the range has been mapped and floored. Reproduce that with a RAID1 llbitmap using 128-sector chunks. A discard starting halfway into chunk 8 with a 128-sector length changed clean bits from 16352 to 16350 and unwritten bits from 0 to 2, even though no chunk was fully discarded. With discard-specific range encoding, both counts stay unchanged for the same test. Range preparation also clamps the pre-map range in the same coordinate space as the incoming IO. RAID5 receives array-sector offsets but tracks llbitmap sync size in component sectors, so steady-state RAID5 must use bitmap_array_sectors() before mapping and keep the existing sync-size clamp after mapping. Reproduce that with a 4-disk RAID5 llbitmap created --assume-clean. A write below dev_sectors changed dirty bits from 0 to 512, but a write at seek=2094080 left the count at 512. With the array-sector pre-map limit, writing at seek=component_size + 65536 increased dirty bits from 512 to 1024. Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-20-yukuai@kernel.org Signed-off-by: Yu Kuai

md: add exact bitmap mapping and reshape hooks

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

Add bitmap mapping and reshape hooks needed by llbitmap reshape support without teaching md core to account a single bio against multiple bitmap ranges. This also adds the old/new bitmap geometry helpers used by personalities to describe reshape mapping to llbitmap. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-13-yukuai@kernel.org Signed-off-by: Yu Kuai

md: add helper to split bios at reshape offset

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

Add mddev_bio_split_at_reshape_offset() so personalities can share reshape-offset bio splitting instead of open-coding the same boundary handling in multiple places. The helper first applies the optional max_sectors limit. If reshape is running and the bio crosses reshape_position, it further limits the front bio to the current reshape boundary so callers can account and submit one side of the reshape at a time. Snapshot reshape_position with READ_ONCE(). RAID5 and RAID10 update this field as reshape progresses, while the I/O path only needs one consistent decision point for the current bio. Using an explicit single load avoids a plain lockless access and prevents the compiler from refetching a different boundary while deciding whether and where to split. When a split is needed, bio_submit_split_bioset() submits the remainder and returns the front bio. Callers must therefore continue processing the returned bio, not the original pointer. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-12-yukuai@kernel.org Signed-off-by: Yu Kuai

md: skip bitmap accounting for empty write ranges

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

mkfs.ext4 can submit zero-sector flush/FUA bios. These bios are WRITE bios for md_write_start() purposes, but they do not cover any data sector and must not dirty bitmap bits. md bitmap accounting currently passes such bios to bitmap start_write(). For llbitmap this reaches llbitmap_start_write() with sectors == 0, which underflows the end chunk calculation. Personality bitmap mapping can also turn a non-empty bio into an empty bitmap range when the requested sectors are outside the active bitmap geometry. Treat both cases as not started, so the completion path will not call end_write() for an empty range. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-11-yukuai@kernel.org Signed-off-by: Yu Kuai

md: avoid stale clone I/O accounting timestamps

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

md_clone_bio() always allocates the clone from mddev->io_clone_set, even when queue I/O stats are disabled. In that case it does not call bio_start_io_acct(), but it also left md_io_clone->start_time untouched. The clone private data comes from a mempool and can contain data from a previous user. md_end_clone_io() checks start_time to decide whether it needs to call bio_end_io_acct(), so a stale non-zero value can make the completion path end accounting that was never started for this bio. Set start_time to 0 in the no-stats branch. This keeps the end path tied to whether bio_start_io_acct() actually ran. Fixes: c687297b8845 ("md: also clone new io if io accounting is disabled") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-8-yukuai@kernel.org Signed-off-by: Yu Kuai

md: wait for behind writes before destroying bitmap

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

__md_stop() destroyed the bitmap before calling mddev_detach(). That made mddev_detach() skip bitmap_ops->wait_behind_writes(), because the bitmap was already disconnected from mddev. This was still safe for the legacy bitmap because bitmap_destroy() waits for behind writes itself. llbitmap keeps that wait in its ->wait_behind_writes() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed. Call mddev_detach() before md_bitmap_destroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone. Fixes: 5ab829f1971d ("md/md-llbitmap: introduce new lockless bitmap") Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-7-yukuai@kernel.org Signed-off-by: Yu Kuai

md/raid1: create serial pool adding rdev to array with serialize_policy=1

2026-07-31T08:26:14+00:00

The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it. Fixes: 69b00b5bb235 ("md: introduce a new struct for IO serialization") Signed-off-by: Martin Wilck Reviewed-by: Mykola Marzhan Link: https://patch.msgid.link/20260723112741.1206836-1-mwilck@suse.com Signed-off-by: Yu Kuai

md: do overflow check for sb->bblog_shift in super_1_load()

2026-07-31T05:35:59+00:00

In super_1_load(), sb->bblog_shift is an __u8 type value loaded from on- disk superblock. It is used for badblocks API badblocks_set() by the following sequence, 1930 rdev->badblocks.shift = sb->bblog_shift; 1931 for (i = 0 ; i < (sectors << (9-3)) ; i++, bbp++) { 1932 u64 bb = le64_to_cpu(*bbp); 1933 int count = bb & (0x3ff); 1934 u64 sector = bb >> 10; 1935 sector <<= sb->bblog_shift; 1936 count <<= sb->bblog_shift; 1937 if (bb + 1 == 0) 1938 break; 1939 if (!badblocks_set(&rdev->badblocks, sector, count, 1)) 1940 return -EINVAL; 1941 } bb->bblog_shit is in range of 0-255, variable sector is 64bit width, for an invalid bb->bblog_shit, it is possible to make sector be overflowed by the following calculation, 1935 sector <<= sb->bblog_shift; Then in turn when call badblocks_set() at line 1939 with the invalid rdev->badblocks.shift set at line 1930, may result an overflow inside _badblocks_clear() in block/badblocks.c. Although there are many places to call badblocks APIs, the non-zero shift value is only used in super_1_load(), other places always use 0 as the shift value. Therefore it is unnecessary to do a general shift value overflow check inside badblock API, and just check here as the caller. This may avoid unnecessary check, make the badblocks API code more simple and elegant. Fixes: 2699b67223ac ("md: load/store badblock list from v1.x metadata") Fixes: 1726c7746783 ("badblocks: improve badblocks_set() for multiple ranges handling") Cc: stable@vger.kernel.org Cc: Ramesh Adhikari Signed-off-by: Coly Li Reviewed-by: Yu Kuai Link: https://patch.msgid.link/20260720111400.2120834-1-colyli@fygo.io Signed-off-by: Yu Kuai