[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025112811-endorse-unclothed-a989@gregkh>
Date: Fri, 28 Nov 2025 07:07:04 +0100
From: Greg KH <greg@...ah.com>
To: Shaurya Rane <ssrane_b23@...vjti.ac.in>
Cc: agruenba@...hat.com, gfs2@...ts.linux.dev, linux-kernel@...r.kernel.org,
skhan@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev,
david.hunter.linux@...il.com, khalid@...nel.org,
syzbot+af4d53576692f8956fd6@...kaller.appspotmail.com
Subject: Re: [PATCH] gfs2: replace BUG_ON with WARN_ON_ONCE in
gfs2_quota_cleanup
On Fri, Nov 28, 2025 at 01:02:47AM +0530, Shaurya Rane wrote:
> gfs2_quota_cleanup() triggers a kernel BUG when called while the
> journal is still marked live and SDF_NORECOVERY is not set. This
> can occur during filesystem withdraw or error recovery paths,
> particularly via gfs2_make_fs_ro() during a reconfigure operation.
>
> The BUG_ON was intended to catch unexpected state where quota
> cleanup runs while the journal is active. However, the cleanup
> code is safe in this scenario because it skips quota entries with
> active references and waits for all references to drain via
> wait_event_timeout().
>
> Crashing the kernel is unnecessarily harsh for what is a
> recoverable situation. Replace the BUG_ON with WARN_ON_ONCE to
> flag the unexpected state for debugging while allowing the
> cleanup to proceed safely.
>
> Reported-by: syzbot+af4d53576692f8956fd6@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=af4d53576692f8956fd6
> Fixes: 71733b492200 ("gfs2: fix kernel BUG in gfs2_quota_cleanup")
> Signed-off-by: Shaurya Rane <ssrane_b23@...vjti.ac.in>
> ---
> fs/gfs2/quota.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index 2298e06797ac..13f113d8aaef 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1516,8 +1516,8 @@ void gfs2_quota_cleanup(struct gfs2_sbd *sdp)
> LIST_HEAD(dispose);
> int count;
>
> - BUG_ON(!test_bit(SDF_NORECOVERY, &sdp->sd_flags) &&
> - test_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags));
> + WARN_ON_ONCE(!test_bit(SDF_NORECOVERY, &sdp->sd_flags) &&
> + test_bit(SDF_JOURNAL_LIVE, &sdp->sd_flags));
You still just rebooted the box if this ever happens (remember
panic-on-warn is enabled on a few billion Linux systems.)
Please fix the root problem here, if this can happen, check it, properly
recover from it, and return the error. Don't just paper over the issue
like this, this is not a fix at all.
thanks,
greg k-h
Powered by blists - more mailing lists