From: Heming Zhao <heming.zhao@suse.com>
To: Ginger Li <ginger.jzllee@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com,
ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ocfs2: Protect local_alloc_state updates in load/shutdown
Date: Tue, 29 Sep 2026 10:59:29 +0800 [thread overview]
Message-ID: <arsnHB6Ak3q4Ztsn@p15> (raw)
In-Reply-To: <20260922060048.13158-1-ginger.jzllee@gmail.com>
On Tue, Sep 22, 2026 at 02:00:48PM +0800, Ginger Li wrote:
> My static analyzer identified a potential issue in 'fs/ocfs2/localalloc.c':
> osb->local_alloc_state is documented as protected by osb->osb_lock in
> struct ocfs2_super, and most of the code follows that rule:
> ocfs2_local_alloc_seen_free_bits(), ocfs2_la_enable_worker() and
> ocfs2_recalc_la_window() all update the field with the lock held.
>
> ocfs2_load_local_alloc() and ocfs2_shutdown_local_alloc() update
> local_alloc_state, and local_alloc_bh next to it, without taking osb_lock, so
> those stores can race with the reads and writes done by the local alloc
> reserve path. Those two writers predate the locking convention and were
> never converted.
>
> Take osb->osb_lock when updating both fields.
>
> Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
> Signed-off-by: Ginger Li <ginger.jzllee@gmail.com>
> ---
> fs/ocfs2/localalloc.c | 6 ++++++
> 1 file changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c
> --- a/fs/ocfs2/localalloc.c
> +++ b/fs/ocfs2/localalloc.c
> @@ -342,8 +342,10 @@ int ocfs2_load_local_alloc(struct ocfs2_super *osb)
> goto bail;
> }
>
> + spin_lock(&osb->osb_lock);
> osb->local_alloc_bh = alloc_bh;
> osb->local_alloc_state = OCFS2_LA_ENABLED;
> + spin_unlock(&osb->osb_lock);
>
This function is triggered during the mount phase. The la (localalloc) is only
active after this point, and the fs is still in the initialization state, so no
inodes can be created. Therefore, we don't need to worry about any race conditions.
> bail:
> if (status < 0)
> @@ -392,7 +394,9 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *os
> goto out;
> }
>
> + spin_lock(&osb->osb_lock);
> osb->local_alloc_state = OCFS2_LA_DISABLED;
> + spin_unlock(&osb->osb_lock);
>
> ocfs2_resmap_uninit(&osb->osb_la_resmap);
>
> @@ -441,8 +445,10 @@ void ocfs2_shutdown_local_alloc(struct ocfs2_super *os
> ocfs2_journal_dirty(handle, bh);
>
> brelse(bh);
> + spin_lock(&osb->osb_lock);
> osb->local_alloc_bh = NULL;
> osb->local_alloc_state = OCFS2_LA_UNUSED;
> + spin_unlock(&osb->osb_lock);
>
> status = ocfs2_sync_local_to_main(osb, handle, alloc_copy,
> main_bm_inode, main_bm_bh);
> --
> 2.43.0
>
When the code enters the umount phase, the VFS layer ensures that there are
no other references to the fs, so no race can occur at this time.
At last, if you have reproducible steps, please provide them to help us
understand the issue better.
Thanks,
Heming
prev parent reply other threads:[~2026-09-29 2:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 6:00 Ginger Li
2026-09-24 16:55 ` Markus Elfring
2026-09-28 8:04 ` Ginger
2026-09-28 8:40 ` Markus Elfring
2026-09-29 2:59 ` Heming Zhao [this message]
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=arsnHB6Ak3q4Ztsn@p15 \
--to=heming.zhao@suse.com \
--cc=ginger.jzllee@gmail.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
/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
all inboxes | Powered by JetHome®