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 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.