From: Christoph Hellwig <hch@infradead.org>
To: Aditya Srivastava <aditya.ansh182@gmail.com>
Cc: Carlos Maiolino <cem@kernel.org>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] xfs: prevent close() from hanging on frozen filesystems
Date: Thu, 11 Jun 2026 22:50:12 -0700 [thread overview]
Message-ID: <aiueFE1yWmLJGIFA@infradead.org> (raw)
In-Reply-To: <20260611180532.1725-1-aditya.ansh182@gmail.com>
Hi Aditya,
this looks mosltly good. A few procedural comments first, I'll then
move on to the code nitpicks.
- please don't respond to the previous patch, always post standalone.
git₋send-email gets this right.
- a lot of the history in this commit log belongs into a cover letter,
not the commit log itself. Same for the reproducer.
- please split this up into multiple patches dong one thing a a time,
e.g.
xfs: add a XFS_TRANS_TRYLOCK flag
xfs: prevent close() from hanging on frozen filesystems
> A simple GPLv2-licensed C reproducer demonstrating the hang (compile
> with -pthread):
Can you also wire this up to xfstests?
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 0ab00615f1ad..56c7919bf1e5 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -574,7 +574,8 @@ xfs_can_free_eofblocks(
> */
> int
> xfs_free_eofblocks(
> - struct xfs_inode *ip)
> + struct xfs_inode *ip,
> + uint flags)
Maybe name this trans_flags so that the usage sticks out?
> @@ -1807,8 +1807,17 @@ xfs_file_release(
> if (!xfs_iflags_test(ip, XFS_EOFBLOCKS_RELEASED) &&
> xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL)) {
> if (xfs_can_free_eofblocks(ip) &&
> - !xfs_iflags_test_and_set(ip, XFS_EOFBLOCKS_RELEASED))
> - xfs_free_eofblocks(ip);
> + !xfs_iflags_test_and_set(ip, XFS_EOFBLOCKS_RELEASED)) {
> + int error = xfs_free_eofblocks(ip, XFS_TRANS_TRYLOCK);
> +
> + /*
> + * If transaction allocation fails due to a frozen/freezing
> + * filesystem, clear the released flag so that subsequent
> + * releases or background blockgc can retry post-thaw.
> + */
> + if (error == -EAGAIN)
> + xfs_iflags_clear(ip, XFS_EOFBLOCKS_RELEASED);
The comment has two overly long lines.
Also the resetting the flag on error is a bit odd. As far as I can tell
there is no need to clear it before the action, so I think we can just
move to clearing it only on successful return, e.g.:
if (!xfs_iflags_test(ip, XFS_EOFBLOCKS_RELEASED) &&
xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL)) {
if (!xfs_iflags_test(ip, XFS_EOFBLOCKS_RELEASED) &&
xfs_can_free_eofblocks(ip) &&
!xfs_free_eofblocks(ip, XFS_TRANS_TRYLOCK))
xfs_iflags_set(ip, XFS_EOFBLOCKS_RELEASED);
> + if (!(flags & XFS_TRANS_NO_WRITECOUNT)) {
> + /*
> + * If TRYLOCK is specified, attempt a non-blocking lock to
> + * avoid blocking indefinitely on frozen/freezing filesystems.
> + */
This would be a bit cleaner as:
if (flags & XFS_TRANS_TRYLOCK) {
if (!sb_start_intwrite_trylock(mp->m_super)) {
kmem_cache_free(xfs_trans_cache, tp);
return ERR_PTR(-EAGAIN);
}
} else if (!(flags & XFS_TRANS_NO_WRITECOUNT)) {
sb_start_intwrite(mp->m_super);
}
And maybe the flag name would better match XFS_TRANS_NO_WRITECOUNT
a bit, e.g. XFS_TRANS_WRITECOUNT_TRYLOCK?
Maybe also add an assert that XFS_TRANS_NO_WRITECOUNT and
XFS_TRANS_NO_WRITECOUNT are not specified at the same time.
next prev parent reply other threads:[~2026-06-12 5:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 13:13 [PATCH] xfs: prevent close() from hanging on frozen filesystems Aditya Srivastava
2026-06-10 13:28 ` Christoph Hellwig
2026-06-11 18:05 ` [PATCH v2] " Aditya Srivastava
2026-06-12 5:50 ` Christoph Hellwig [this message]
2026-06-12 11:07 ` Aditya Prakash Srivastava
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=aiueFE1yWmLJGIFA@infradead.org \
--to=hch@infradead.org \
--cc=aditya.ansh182@gmail.com \
--cc=cem@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@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