From: sashiko-bot@kernel.org
To: "Yu Kuai" <yukuai@kernel.org>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH v2 06/20] md/md-llbitmap: grow the page cache in place for reshape
Date: Wed, 24 Jun 2026 07:03:52 +0000 [thread overview]
Message-ID: <20260624070352.CD0E21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <27639f9aceb3cb6d6d021df79f9f6839d916bb58.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The `LLPageFlush` bit on existing cached pages is set during `llbitmap_flush()` but never cleared, permanently bypassing the barrier idle expiration timer and causing severe metadata write amplification.
- [High] Reallocating `llbitmap->pctl` locklessly in place causes a Use-After-Free for concurrent I/O paths and the background daemon.
Pre-existing issues:
- [High] An integer overflow in chunk size calculation on 32-bit systems causes a fatal divide-by-zero for extremely large arrays.
--
commit 06efa66cdd24523c6bea3b2de073842d179f3506
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: grow the page cache in place for reshape
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.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 4c3fc4b35aff0..98e7824c7362e 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -416,6 +416,19 @@ static char state_machine[BitStateCount][BitmapActionCount] = {
> };
>
> static void __llbitmap_flush(struct mddev *mddev);
> +static void llbitmap_flush(struct mddev *mddev);
> +static void llbitmap_update_sb(void *data);
> +
> +static void llbitmap_calculate_chunks(struct mddev *mddev, sector_t blocks,
> + unsigned long *chunksize,
> + unsigned long *chunks)
> +{
> + *chunks = DIV_ROUND_UP_SECTOR_T(blocks, *chunksize);
> + while (*chunks > mddev->bitmap_info.space << SECTOR_SHIFT) {
> + *chunksize = *chunksize << 1;
> + *chunks = DIV_ROUND_UP_SECTOR_T(blocks, *chunksize);
[Severity: High]
This isn't a bug introduced by this patch, but since `chunksize` is an
`unsigned long` (32 bits on 32-bit architectures) and `blocks` is a 64-bit
`sector_t`, could the left shift push `*chunksize` past 31 bits and overflow
it to 0 for extremely large arrays?
If `*chunksize` becomes 0, does this cause a divide-by-zero panic in the
`DIV_ROUND_UP_SECTOR_T()` macro?
> + }
> +}
[ ... ]
> +static int llbitmap_expand_pages(struct llbitmap *llbitmap,
> + unsigned long chunks)
> +{
> + struct llbitmap_page_ctl **pctl;
> + unsigned int old_nr_pages = llbitmap->nr_pages;
> + unsigned int nr_pages = llbitmap_used_pages(llbitmap, chunks);
> + unsigned int i;
> + int ret;
> +
> + if (nr_pages <= old_nr_pages)
> + return 0;
> +
> + pctl = kcalloc(nr_pages, sizeof(*pctl), GFP_KERNEL);
> + if (!pctl)
> + return -ENOMEM;
> +
> + if (llbitmap->pctl)
> + memcpy(pctl, llbitmap->pctl,
> + array_size(old_nr_pages, sizeof(*pctl)));
> +
> + for (i = old_nr_pages; i < nr_pages; i++) {
> + pctl[i] = llbitmap_alloc_page_ctl(llbitmap, i);
> + if (IS_ERR(pctl[i]))
> + goto err_alloc_ptr;
> + }
> +
> + kfree(llbitmap->pctl);
> + llbitmap->pctl = pctl;
> + llbitmap->nr_pages = nr_pages;
[Severity: High]
Is it safe to reallocate and update `llbitmap->pctl` and `nr_pages` locklessly
in place like this while the array is processing I/O?
`llbitmap_resize()` holds only `mddev->bitmap_info.mutex`, but concurrent
lockless readers like `md_llbitmap_daemon_fn()` and the I/O fastpath
`llbitmap_start_write()` dereference `llbitmap->pctl[idx]`.
Could this lead to a Use-After-Free if a concurrent reader accesses the old
`llbitmap->pctl` array just as it gets freed?
> + return 0;
> +
> +err_alloc_ptr:
> + ret = PTR_ERR(pctl[i]);
[ ... ]
> +static int llbitmap_prepare_resize(struct llbitmap *llbitmap,
> + unsigned long old_chunks,
> + unsigned long new_chunks,
> + unsigned long cache_chunks)
> +{
> + int ret;
> +
> + llbitmap_flush(llbitmap->mddev);
> + ret = llbitmap_expand_pages(llbitmap, cache_chunks);
[Severity: High]
Does this sequence cause the daemon thread to bypass the barrier idle timer and
create severe metadata write amplification?
`llbitmap_flush()` sets the `LLPageFlush` bit on all existing pages. Since
`llbitmap_expand_pages()` reuses the existing `pctl` structures, the active
pages are retained with the `LLPageFlush` bit still set.
Since this bit is never cleared, the check in `md_llbitmap_daemon_fn()`:
if (!test_bit(LLPageFlush, &pctl->flags) &&
time_before(jiffies, pctl->expire)) {
restart = true;
continue;
}
will permanently fail for these pages, forcing the daemon to immediately flush
them and skip re-arming the pending timer.
> + if (ret)
> + return ret;
> + if (new_chunks > old_chunks)
> + llbitmap_mark_range(llbitmap, old_chunks, new_chunks - 1,
> + BitUnwritten);
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=6
next prev parent reply other threads:[~2026-06-24 7:03 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 9:15 [PATCH 00/20] md/md-llbitmap: support reshape for RAID10 and RAID5 Yu Kuai
2026-06-05 9:15 ` [PATCH] md: add exact bitmap mapping and reshape hooks Yu Kuai
2026-06-05 9:15 ` [PATCH] md: skip bitmap accounting for empty write ranges Yu Kuai
2026-06-05 9:15 ` [PATCH] md: add helper to split bios at reshape offset Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: track bitmap sync_size explicitly Yu Kuai
2026-06-15 10:48 ` Su Yue
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: allocate page controls independently Yu Kuai
2026-06-15 11:06 ` Su Yue
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: grow the page cache in place for reshape Yu Kuai
2026-06-15 11:16 ` Su Yue
2026-06-15 16:19 ` yu kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: track target reshape geometry fields Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: finish reshape geometry Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: refuse reshape while llbitmap still needs sync Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: add reshape range mapping helpers Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: don't skip reshape ranges from bitmap state Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: remap checkpointed bits as reshape progresses Yu Kuai
2026-06-05 9:15 ` [PATCH] md/md-llbitmap: clamp state-machine walks to tracked bits Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid10: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid10: wire llbitmap reshape lifecycle Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid10: split reshape bios before bitmap accounting Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid5: add exact old and new llbitmap mapping helpers Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid5: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid5: wire llbitmap reshape lifecycle Yu Kuai
2026-06-05 9:15 ` [PATCH] md/raid5: split reshape bios before bitmap accounting Yu Kuai
2026-06-05 17:27 ` kernel test robot
2026-06-06 2:15 ` kernel test robot
2026-06-24 6:41 ` [PATCH v2 00/20] md/md-llbitmap: support reshape for RAID10 and RAID5 Yu Kuai
2026-06-24 6:41 ` [PATCH v2 01/20] md: add exact bitmap mapping and reshape hooks Yu Kuai
2026-06-24 6:41 ` [PATCH v2 02/20] md: skip bitmap accounting for empty write ranges Yu Kuai
2026-06-24 7:04 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 03/20] md: add helper to split bios at reshape offset Yu Kuai
2026-06-24 7:01 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 04/20] md/md-llbitmap: track bitmap sync_size explicitly Yu Kuai
2026-06-24 7:02 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 05/20] md/md-llbitmap: allocate page controls independently Yu Kuai
2026-06-24 7:02 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 06/20] md/md-llbitmap: grow the page cache in place for reshape Yu Kuai
2026-06-24 7:03 ` sashiko-bot [this message]
2026-06-24 6:42 ` [PATCH v2 07/20] md/md-llbitmap: track target reshape geometry fields Yu Kuai
2026-06-24 7:07 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 08/20] md/md-llbitmap: finish reshape geometry Yu Kuai
2026-06-24 9:06 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 09/20] md/md-llbitmap: refuse reshape while llbitmap still needs sync Yu Kuai
2026-06-24 7:04 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 10/20] md/md-llbitmap: add reshape range mapping helpers Yu Kuai
2026-06-24 7:08 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 11/20] md/md-llbitmap: don't skip reshape ranges from bitmap state Yu Kuai
2026-06-24 6:58 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 12/20] md/md-llbitmap: remap checkpointed bits as reshape progresses Yu Kuai
2026-06-24 7:04 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 13/20] md/md-llbitmap: clamp state-machine walks to tracked bits Yu Kuai
2026-06-24 7:06 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 14/20] md/raid10: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-06-24 6:42 ` [PATCH v2 15/20] md/raid10: wire llbitmap reshape lifecycle Yu Kuai
2026-06-24 7:22 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 16/20] md/raid10: split reshape bios before bitmap accounting Yu Kuai
2026-06-24 7:20 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 17/20] md/raid5: add exact old and new llbitmap mapping helpers Yu Kuai
2026-06-24 7:16 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 18/20] md/raid5: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-06-24 7:24 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 19/20] md/raid5: wire llbitmap reshape lifecycle Yu Kuai
2026-06-24 7:20 ` sashiko-bot
2026-06-24 6:42 ` [PATCH v2 20/20] md/raid5: split reshape bios before bitmap accounting Yu Kuai
2026-06-24 7:29 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260624070352.CD0E21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yukuai@fygo.io \
--cc=yukuai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox