Linux XFS filesystem development
 help / color / mirror / Atom feed
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.


  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