Re: [PATCH v5 17/29] md/md-llbitmap: finish reshape geometry

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `reshape_finish` callback is never invoked by the md core, rendering the new geometry commit logic dead code.
- [High] In-flight I/O during an array reshape triggers an out-of-bounds array access in `llbitmap_raise_barrier` due to stale chunkshift values.
--

--- Patch [17]: [PATCH v5 17/29] md/md-llbitmap: finish reshape geometry ---

commit f7a8f4b26cc5a0c01433cbcd7568266fb367e5e1
Author: Yu Kuai [off-list ref]

md/md-llbitmap: finish reshape geometry

This commit updates the llbitmap reshape geometry when the reshape finishes.
It refreshes the staged reshape geometry in llbitmap_load() after mddev->pers
is available, and expands the in-memory page controls before replaying the
bitmap state.

Link: https://lore.kernel.org/all/20260726185916.2223460-1-mykola@meshstor.io/ (local)

[ ... ]

[Severity: High]
Does this introduce a regression where in-flight I/O during an array
reshape triggers an out-of-bounds array access due to stale chunkshift
values before they are updated here?

When an array grows, the active chunkshift remains unchanged while the page
controls are allocated for the old chunk limit. If the new chunksize is
forced to double, the new I/O offsets mapping to the expanded capacity
could be processed by llbitmap_start_write():

drivers/md/md-llbitmap.c:llbitmap_start_write() {
    unsigned long start = offset >> llbitmap->chunkshift;
    unsigned long end = (offset + sectors - 1) >> llbitmap->chunkshift;
    int page_start = (start + BITMAP_DATA_OFFSET) >> PAGE_SHIFT;
    ...
    llbitmap_raise_barrier(llbitmap, page_start);
}

Dividing the larger offset by the old, smaller chunkshift would generate a
bit index that exceeds the old chunks.

Would this result in an out-of-bounds read/write without bounds checking
when llbitmap_raise_barrier() is called?

drivers/md/md-llbitmap.c:llbitmap_raise_barrier() {
    ...
    struct llbitmap_page_ctl *pctl = llbitmap->pctl[page_idx];
    ...
}

+	llbitmap->chunks = llbitmap->reshape_chunks;
+	llbitmap->sync_size = llbitmap->reshape_sync_size;
+	llbitmap_refresh_reshape(llbitmap);
+	mddev->bitmap_info.chunksize = llbitmap->chunksize;
+	llbitmap_update_sb(llbitmap);
+	__llbitmap_flush(mddev);
+	mutex_unlock(&mddev->bitmap_info.mutex);
+
+	if (mddev->pers->quiesce)
+		mddev->pers->quiesce(mddev, 0);
+}
+

[ ... ]

[Severity: High]
Is there a regression where the md core never calls this reshape_finish
callback?

Looking at the md core code, it does not appear to invoke
mddev->bitmap_ops->reshape_finish anywhere. If this is never called, would
the staged reshape geometry be silently dropped, leaving the bitmap
permanently out of sync with the expanded array capacity after a reshape
completes?

 	.write_all		= llbitmap_write_all,
 
 	.groups			= md_llbitmap_groups,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260802195038.164272-1-yukuai@kernel.org?part=17