From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: gfs2@lists.linux.dev, linux-kernel@vger.kernel.org,
Joseph Qi <joseph.qi@linux.alibaba.com>,
stable@vger.kernel.org
Subject: [PATCH 1/2] gfs2: release the statfs glock when gfs2_clear_beyond_eof() fails
Date: Thu, 5 Nov 2026 13:46:08 +0800 [thread overview]
Message-ID: <20261105054609.2759418-1-joseph.qi@linux.alibaba.com> (raw)
gfs2_file_buffered_write() acquires the master statfs glock before
writing to the rindex and releases it once the write is done. The only
error path in between used to be the failure of that acquisition, which
gfs2_glock_nq_init() unwinds by itself, so the cleanup code at the end of
the function never had to deal with a held statfs glock.
Commit 4982e58669b1 ("gfs2: page poisoning fix") added a call to
gfs2_clear_beyond_eof() right after the acquisition and made it jump to
out_unlock on failure. That path only drops the inode glock and then
frees statfs_gh, so a failed write to the rindex leaves the master
statfs glock held exclusively and frees a holder that is still linked
into the glock's holder list. The GL_NOCACHE demote is requested by
__gfs2_glock_dq(), which is never reached, so the glock stays locked for
the rest of the mount, and the glock and pid references taken by
__gfs2_holder_init() leak as well. Walking the stale list entry later
on, for instance from do_promote() or from a demote callback, is a
use-after-free.
gfs2_clear_beyond_eof() zeroes the space beyond eof, which for the
rindex ends up in adjust_fs_space(), so the call cannot be moved out
from under the statfs glock. Release the holder in the error path
instead, guarded by gfs2_holder_initialized() so that the paths which
never acquired it and the one which already released it are unaffected.
Fixes: 4982e58669b1 ("gfs2: page poisoning fix")
Cc: stable@vger.kernel.org
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
---
fs/gfs2/file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 1efd0679badd9..2452d3ecf09c7 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -1087,6 +1087,8 @@ static ssize_t gfs2_file_buffered_write(struct kiocb *iocb,
goto retry;
}
out_unlock:
+ if (inode == sdp->sd_rindex && gfs2_holder_initialized(statfs_gh))
+ gfs2_glock_dq_uninit(statfs_gh);
if (gfs2_holder_queued(gh))
gfs2_glock_dq(gh);
out_uninit:
--
2.39.3
next reply other threads:[~2026-11-05 5:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 5:46 Joseph Qi [this message]
2026-11-05 5:46 ` [PATCH 2/2] gfs2: hold the master statfs glock while operating on the rindex Joseph Qi
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=20261105054609.2759418-1-joseph.qi@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=agruenba@redhat.com \
--cc=gfs2@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.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
all inboxes | Powered by JetHome®