From: sashiko-bot@kernel.org
To: "Yu Kuai" <yukuai@kernel.org>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH v5 09/29] md/md-llbitmap: stop daemon timer rearm on destroy
Date: Sun, 02 Aug 2026 20:19:03 +0000 [thread overview]
Message-ID: <20260802201904.53BD81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802195038.164272-10-yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Time-of-check to time-of-use (TOCTOU) race in the teardown path allows the timer to be re-armed after deletion, causing a use-after-free.
--
--- Patch [9]: [PATCH v5 09/29] md/md-llbitmap: stop daemon timer rearm on destroy ---
commit ea383c856bd9022c7e57c7a025fcf8fb539acf1e
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: stop daemon timer rearm on destroy
This commit attempts to fix a race where the daemon timer is re-armed
during array teardown. It adds a BITMAP_SHUTDOWN flag, sets it before
deleting the timer and canceling the daemon work, and checks the flag
before queuing or rearming the work.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> @@ -1096,7 +1103,7 @@ static void md_llbitmap_daemon_fn(struct work_struct *work)
> goto retry;
>
> /* If some page is dirty but not expired, setup timer again */
> - if (restart)
> + if (restart && !test_bit(BITMAP_SHUTDOWN, &llbitmap->flags))
> mod_timer(&llbitmap->pending_timer,
> jiffies + llbitmap->mddev->bitmap_info.daemon_sleep * HZ);
> }
[ ... ]
> @@ -1179,7 +1186,9 @@ static void llbitmap_destroy(struct mddev *mddev)
>
> mutex_lock(&mddev->bitmap_info.mutex);
>
> + set_bit(BITMAP_SHUTDOWN, &llbitmap->flags);
> timer_delete_sync(&llbitmap->pending_timer);
> + cancel_work_sync(&llbitmap->daemon_work);
> flush_workqueue(md_llbitmap_io_wq);
> flush_workqueue(md_llbitmap_unplug_wq);
[Severity: High]
This isn't a bug introduced by this patch, but does this teardown sequence
still leave a race condition that can result in a use-after-free?
Since the BITMAP_SHUTDOWN check and mod_timer() in md_llbitmap_daemon_fn()
are not atomic, a worker can evaluate BITMAP_SHUTDOWN as false but get
preempted before arming the timer.
Concurrently, llbitmap_destroy() sets BITMAP_SHUTDOWN, calls
timer_delete_sync() (which returns immediately if the timer isn't pending),
and blocks in cancel_work_sync().
When the preempted worker resumes, it executes mod_timer(), re-arming the
timer. Once the worker finishes, cancel_work_sync() unblocks and
llbitmap_destroy() frees llbitmap, leaving the timer armed and able to
access freed memory when it fires.
Would replacing timer_delete_sync() with timer_shutdown_sync() safely
prevent any subsequent mod_timer() calls from succeeding?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260802195038.164272-1-yukuai@kernel.org?part=9
next prev parent reply other threads:[~2026-08-02 20:19 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 19:50 [PATCH v5 00/29] md: improve lockless bitmap reshape support Yu Kuai
2026-08-02 19:50 ` [PATCH v5 01/29] md/md-llbitmap: clear flush state after daemon flush Yu Kuai
2026-08-02 20:28 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 02/29] md/md-llbitmap: use GFP_NOIO for cache allocations Yu Kuai
2026-08-02 20:44 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 03/29] md/md-llbitmap: only end fully synced chunks Yu Kuai
2026-08-02 19:50 ` [PATCH v5 04/29] md/raid5: reject zero-sector reshape chunks Yu Kuai
2026-08-02 20:31 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 05/29] md/raid5: round bitmap stripes with sector division Yu Kuai
2026-08-02 20:19 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 06/29] md: wait for behind writes before destroying bitmap Yu Kuai
2026-08-02 20:40 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 07/29] md: avoid stale clone I/O accounting timestamps Yu Kuai
2026-08-02 20:45 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 08/29] md/md-llbitmap: prevent create failure bitmap UAF Yu Kuai
2026-08-02 20:39 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 09/29] md/md-llbitmap: stop daemon timer rearm on destroy Yu Kuai
2026-08-02 20:19 ` sashiko-bot [this message]
2026-08-02 19:50 ` [PATCH v5 10/29] md: skip bitmap accounting for empty write ranges Yu Kuai
2026-08-02 19:50 ` [PATCH v5 11/29] md: add helper to split bios at reshape offset Yu Kuai
2026-08-02 20:19 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 12/29] md: add exact bitmap mapping and reshape hooks Yu Kuai
2026-08-02 19:50 ` [PATCH v5 13/29] md/md-llbitmap: track bitmap sync_size explicitly Yu Kuai
2026-08-02 20:24 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 14/29] md/md-llbitmap: allocate page controls independently Yu Kuai
2026-08-02 20:27 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 15/29] md/md-llbitmap: grow the page cache in place for reshape Yu Kuai
2026-08-02 20:37 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 16/29] md/md-llbitmap: track target reshape geometry fields Yu Kuai
2026-08-02 20:25 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 17/29] md/md-llbitmap: finish reshape geometry Yu Kuai
2026-08-02 20:39 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 18/29] md/md-llbitmap: refuse reshape while llbitmap still needs sync Yu Kuai
2026-08-02 20:44 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 19/29] md/md-llbitmap: add reshape range mapping helpers Yu Kuai
2026-08-02 20:31 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 20/29] md/md-llbitmap: don't skip reshape ranges from bitmap state Yu Kuai
2026-08-02 20:31 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 21/29] md/md-llbitmap: remap checkpointed bits as reshape progresses Yu Kuai
2026-08-02 20:43 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 22/29] md/md-llbitmap: clamp state-machine walks to tracked bits Yu Kuai
2026-08-02 19:50 ` [PATCH v5 23/29] md/raid10: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-08-02 20:40 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 24/29] md/raid10: wire llbitmap reshape lifecycle Yu Kuai
2026-08-02 20:49 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 25/29] md/raid10: split reshape bios before bitmap accounting Yu Kuai
2026-08-02 20:46 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 26/29] md/raid5: add exact old and new llbitmap mapping helpers Yu Kuai
2026-08-02 19:50 ` [PATCH v5 27/29] md/raid5: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-08-02 20:42 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 28/29] md/raid5: wire llbitmap reshape lifecycle Yu Kuai
2026-08-02 20:46 ` sashiko-bot
2026-08-02 19:50 ` [PATCH v5 29/29] md/raid5: split reshape bios before bitmap accounting Yu Kuai
2026-08-03 12:11 ` [PATCH v5 00/29] md: improve lockless bitmap reshape support Mykola Marzhan
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=20260802201904.53BD81F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.