Re: [PATCH v4 14/25] md/md-llbitmap: refuse reshape while llbitmap still needs sync

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

New issues:
- [Medium] The newly added `llbitmap_reshape_can_start` callback is never e=
xecuted because there are no callers for `mddev->bitmap_ops->reshape_can_st=
art` anywhere in the md codebase.

Pre-existing issues:
- [High] Use-After-Free in the `llbitmap_create` error path where `mddev->b=
itmap` points to freed memory without holding the lock.
--

--- Patch [14]: [PATCH v4 14/25] md/md-llbitmap: refuse reshape while llbit=
map still needs sync ---
commit a811c308c426ffe3f23803b0888eecbb420a8f6d
Author: Yu Kuai <[email protected]>

md/md-llbitmap: refuse reshape while llbitmap still needs sync

Reject reshape when llbitmap still contains NeedSync or Syncing bits. This
keeps reshape from starting until the current llbitmap state has been
reconciled.

> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index f41f9ba2063b5..3b121b372cd8d 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> @@ -2025,6 +2048,7 @@ static struct bitmap_operations llbitmap_ops =3D {
>  	.dirty_bits		=3D llbitmap_dirty_bits,
>  	.prepare_range		=3D llbitmap_prepare_range,
>  	.reshape_finish		=3D llbitmap_reshape_finish,
> +	.reshape_can_start	=3D llbitmap_reshape_can_start,
>  	.write_all		=3D llbitmap_write_all,

[Severity: Medium]
Is this callback executed by the md core?

Looking at the md codebase, there do not appear to be any callers for
mddev->bitmap_ops->reshape_can_start. Does this mean the validation logic
is bypassed and reshapes could still start prematurely?

[Severity: High]
This is a pre-existing issue, but can a concurrent reader access freed memo=
ry
during bitmap creation?

In llbitmap_create(), if an error occurs, the mutex is dropped before
mddev->bitmap is set to NULL:

    mutex_unlock(&mddev->bitmap_info.mutex);
    if (ret) {
        kfree(llbitmap);
        mddev->bitmap =3D NULL;
    }

A concurrent /proc/mdstat reader could acquire the mutex after it is dropped
but before mddev->bitmap is cleared, allowing it to dereference the freed
llbitmap pointer:

drivers/md/md.c:md_seq_show() {
    ...
    /* prevent bitmap to be freed after checking */
    mutex_lock(&mddev->bitmap_info.mutex);
    ...
        md_bitmap_status(seq, mddev);
    ...
}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260801172519.2982=
[email protected]?part=3D14