kernel/git/next/linux-next.git/drivers/md/md-llbitmap.c, branch master

md/md-llbitmap: clamp state-machine walks to tracked bits

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

llbitmap_state_machine() can be called with an end bit beyond llbitmap->chunks. In particular, llbitmap_cond_end_sync() passes sector >> chunkshift, and sector can reach the tracked boundary exactly. Clamp the state-machine range to llbitmap->chunks so it cannot walk past the tracked bitmap. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-23-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: remap checkpointed bits as reshape progresses

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

Merge checkpointed old llbitmap state forward as reshape_position advances and record the checkpoint remap through reshape_mark(). Normal write accounting can run while the reshape thread checkpoints a new reshape position. llbitmap_reshape_mark() reads old state bytes, merges them into destination bits, and writes the result back. If llbitmap_start_write() or llbitmap_start_discard() updates the same state bytes at the same time, the two read/modify/write paths can overwrite each other and lose the state from one side. Serialize only this state-byte race with a rwlock. Normal I/O takes the read side around llbitmap_state_machine(), after page active references are raised, so concurrent normal I/O updates still run in parallel. Reshape checkpointing takes the write side only while merging the checkpointed range, avoiding page suspension and avoiding a sleeping mutex in the I/O accounting path. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-22-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: don't skip reshape ranges from bitmap state

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

Reshape progress is tracked by array metadata rather than llbitmap. Do not let llbitmap skip_sync_blocks() suppress reshape ranges based on stale bitmap state before the corresponding checkpoint is persisted. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-21-yukuai@kernel.org 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/md-llbitmap: refuse reshape while llbitmap still needs sync

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

Reject reshape when llbitmap still contains NeedSync or Syncing bits. This keeps reshape from starting until the current llbitmap state has been reconciled. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-19-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: finish reshape geometry

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

Commit the staged llbitmap geometry when reshape finishes. When assembling a stopped reshape, md_run() creates the bitmap before publishing mddev->pers. llbitmap_read_sb() can therefore only initialize the reshape fields from the old on-disk sync size. Refresh the staged reshape geometry again from llbitmap_load(), after mddev->pers is available, and expand the in-memory page controls before replaying bitmap state. Reproduce on the old kernel by creating a RAID10 llbitmap with four active disks and two spares, growing it to six disks, then stopping and assembling while reshape is still running. The llbitmap chunk count was 32704 before grow, 49056 during reshape, then rolled back to 32704 after reassemble. The fixed kernel kept the target geometry across the same stop/reassemble flow: 65440 chunks before grow, 98160 during reshape, and 98160 after reassemble. Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-18-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: track target reshape geometry fields

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

Track llbitmap bookkeeping for the target reshape geometry while keeping a single live bitmap instance. Add the reshape geometry fields, refresh helper, and update the load and resize paths to keep the target geometry in sync. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-17-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: grow the page cache in place for reshape

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

Use the page-control helpers to grow llbitmap's cached pages in place for resize and later reshape preparation, instead of rebuilding the whole cache. Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-16-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: allocate page controls independently

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

Allocate one llbitmap page-control object at a time and free each object through the same model. Let llbitmap_read_page() return a zeroed page without reading disk when the page index is beyond the current bitmap size, so page-control allocation no longer needs a separate read_existing flag. This keeps the llbitmap page-control lifetime self-consistent and prepares the page-cache code for later in-place growth. Reviewed-by: Su Yue Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-15-yukuai@kernel.org Signed-off-by: Yu Kuai

md/md-llbitmap: track bitmap sync_size explicitly

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

Track llbitmap's own sync_size instead of always using mddev->resync_max_sectors directly. This is the minimal bookkeeping needed before llbitmap can track old and new reshape geometry independently. Reviewed-by: Su Yue Tested-by: Mykola Marzhan Link: https://patch.msgid.link/20260802195038.164272-14-yukuai@kernel.org Signed-off-by: Yu Kuai