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

[sashiko-bot@kernel.org]

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 executed because there are no callers for `mddev->bitmap_ops->reshape_can_start` anywhere in the md codebase.

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

--- Patch [14]: [PATCH v4 14/25] md/md-llbitmap: refuse reshape while llbitmap still needs sync ---
commit a811c308c426ffe3f23803b0888eecbb420a8f6d
Author: Yu Kuai <yukuai@fygo.io>

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 = {
>  	.dirty_bits		= llbitmap_dirty_bits,
>  	.prepare_range		= llbitmap_prepare_range,
>  	.reshape_finish		= llbitmap_reshape_finish,
> +	.reshape_can_start	= llbitmap_reshape_can_start,
>  	.write_all		= 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 memory
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 = 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);
    ...
}

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