From: Aditya Prakash Srivastava <aditya.ansh182@gmail.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
Christoph Hellwig <hch@lst.de>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Aditya Prakash Srivastava <aditya.ansh182@gmail.com>
Subject: [PATCH v6 0/1] xfs: prevent close() hangs on frozen filesystems
Date: Mon, 14 Sep 2026 09:31:50 +0000 [thread overview]
Message-ID: <20260914093152.1698-1-aditya.ansh182@gmail.com> (raw)
Hi Christoph, Darrick, and Carlos,
This is version 6 of the patch series addressing the close() system
call hanging indefinitely on frozen XFS filesystems (Bugzilla #205833).
In v5, I introduced a transaction allocation flag
(XFS_TRANS_WRITECOUNT_TRYLOCK) to handle the trylock inside
__xfs_trans_alloc() and propagated it down to xfs_free_eofblocks().
Christoph suggested this design and reviewed the implementation.
However, Darrick suggested that the deadlock can be resolved much
more simply at the VFS-layer within xfs_file_release() by surrounding
the existing check with sb_start_write_trylock() instead of passing
transaction allocation flags all the way down.
This v6 implements that VFS-layer trylock approach. It modifies only a
single file (fs/xfs/xfs_file.c). If sb_start_write_trylock() fails (meaning
the filesystem is frozen or freezing), we simply skip the speculative
preallocation trim.
I would appreciate your guidance on which of the two architectural
paths is preferred for XFS:
1. The v5 transaction-flag approach (centralized within xfs_trans_alloc).
2. The v6 VFS-level trylock approach (localized within xfs_file_release).
If the v5 approach is preferred, I will rebase the transaction-flag
patches onto the current master and submit them as a new version.
Thanks,
Aditya
Aditya Prakash Srivastava (1):
xfs: prevent close() from hanging on frozen filesystems
fs/xfs/xfs_file.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
--
2.47.3
next reply other threads:[~2026-09-14 9:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 9:31 Aditya Prakash Srivastava [this message]
2026-09-14 9:31 ` [PATCH v6 1/1] xfs: prevent close() from hanging on frozen filesystems Aditya Prakash Srivastava
2026-09-14 14:59 ` Darrick J. Wong
2026-09-15 6:37 ` Christoph Hellwig
2026-09-16 12:06 ` [PATCH v6 0/1] xfs: prevent close() hangs " Carlos Maiolino
-- strict thread matches above, loose matches on Subject: below --
2026-09-14 8:28 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=20260914093152.1698-1-aditya.ansh182@gmail.com \
--to=aditya.ansh182@gmail.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--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.