From: "Darrick J. Wong" <djwong@kernel.org>
To: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: Dave Chinner <dgc@kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
John Garry <john.garry@linux.dev>
Subject: Re: [bug report] fstests generic/774 hang again
Date: Fri, 25 Sep 2026 16:03:29 -0700 [thread overview]
Message-ID: <20260925230329.GE2705364@frogsfrogsfrogs> (raw)
In-Reply-To: <arXPSS6ikVMDaI7w@shinmob>
On Fri, Sep 25, 2026 at 10:38:07AM +0900, Shin'ichiro Kawasaki wrote:
> On Sep 21, 2026 / 17:28, Darrick J. Wong wrote:
> > On Thu, Sep 17, 2026 at 07:45:04AM +1000, Dave Chinner wrote:
> [...]
> > > A bunch of threads waiting on the ILOCK here:
> > >
> > > down_write_nested+0x1c0/0x1f0
> > > xfs_reflink_end_atomic_cow+0x2f3/0x560 [xfs]
> > > xfs_dio_write_end_io+0x4b7/0x650 [xfs]
> > > iomap_dio_complete+0x140/0xb20
> > > iomap_dio_complete_work+0x58/0x90
> > > process_one_work+0x947/0x1760
> > >
> > > And the holder:
> > >
> > > schedule+0xe5/0x2e0
> > > xlog_grant_head_wait+0x175/0xac0 [xfs]
> > > xlog_grant_head_check+0x312/0x3f0 [xfs]
> > > xfs_log_regrant+0x380/0x7d0 [xfs]
> > > xfs_trans_roll+0x2d9/0x420 [xfs]
> > > xfs_defer_trans_roll+0x11e/0x4b0 [xfs]
> > > xfs_defer_finish_noroll+0x460/0xe70 [xfs]
> > > xfs_trans_commit+0xfc/0x180 [xfs]
> > > xfs_reflink_end_atomic_cow+0x3b2/0x560 [xfs]
> > > xfs_dio_write_end_io+0x4b7/0x650 [xfs]
> > > iomap_dio_complete+0x140/0xb20
> > > iomap_dio_complete_work+0x58/0x90
> > > process_one_work+0x947/0x1760
> > >
> > > is waiting on log space whilst holding the ILOCK.
> > >
> > > This looks to me like the test runs out of log space because of all
> > > the IO completions holding transaction reservations waiting on the
> > > ILOCK, whilst the ILOCK holder can't get enough log space to regrant
> > > on transaction roll to continue the transaction.
> >
> > Agreed.
> >
> > Why are we calling xlog_grant_head_check from within
> > xfs_reflink_end_atomic_cow? I think the reason for doing that is
> > because we've exhausted t_cnt in the ticket (i.e. we've already rolled
> > more than tr_logcount times).
> >
> > Oh. tr_atomic_ioend.tr_logcount is 5 on a rmap+reflink filesystem,
> > which it inherits from tr_itruncate. However, tr_itruncate is only
> > intended to remove two extents from a file, so it only needs 5 rolls.
> > Coincidentally we calculate 5 rolls for each atomic extent remapping
> > operation.
> >
> > For atomic write ioends, what if we increased tr_logcount to 5x the
> > number of remappings that would have to occur to finish the write?
> > That would preallocate all the permanent reservation we'd need before we
> > take the ILOCK, which avoids the situation of needing to obtain more log
> > space while holding ILOCK.
> >
> > The downside is that you'd have to limit the software awu_max even
> > further, perhaps to 40% of the log size divided by
> > (tr_logres*tr_logcount). However, we'd still be able to handle
> > concurrent atomic writes to different parts of the file, at least until
> > fragmentation got bad.
>
> Darrick, thanks for the idea. I wanted to try out the idea, so I cooled
> the experimental patch below. Is this what you meant? It is a very rough
> patch, and does not reflect the "limit the software awu_max even further"
> part, it is just for experiment.
>
> Anyway, I applied this patch on top of the kernel xfs/for-next branch git
> hash 0ca15a1a1151, and repeated the test case g774. It did not hang after
> 100 times repeat, so it looks working.
>
>
> From c90ec246b0b9e14097b0ad1d1ef5661261dd61db Mon Sep 17 00:00:00 2001
> From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Date: Thu, 24 Sep 2026 19:08:32 +0900
> Subject: [PATCH] xfs: try out Darrick's idea for g774 hang
>
> [experimental patch]
>
> Darrick's idea from
> https://lore.kernel.org/linux-xfs/20260922002814.GK2705364@frogsfrogsfrogs/
>
> The deadlock of g774 caused by grant space while holding ILOCK. To avoid the
> deadlock, allocate enough space before taking the ILOCK by increasing
> tr_logcount. 5 rolls are required for each extent, then multiply tr_logcount
> by 5.
> ---
> fs/xfs/xfs_reflink.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index 48013613663..9d3da713a01 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -1020,6 +1020,28 @@ xfs_reflink_end_cow(
> return error;
> }
>
> +/*
> + * Number of transaction rolls needed to remap a single extent during an atomic
> + * write ioend.
> + */
> +#define XFS_ATOMIC_IOEND_ROLLS 5
> +
> +/*
> + * Compute the number of log operations to reserve for an atomic write ioend
> + * that remaps @blockcount blocks with a @logres byte reservation.
> + */
> +STATIC int
> +xfs_calc_atomic_write_ioend_logcount(
> + struct xfs_mount *mp,
> + xfs_extlen_t blockcount,
> + unsigned int logres)
> +{
> + if (blockcount == 0 || logres == 0)
> + return M_RES(mp)->tr_atomic_ioend.tr_logcount;
> +
> + return blockcount * XFS_ATOMIC_IOEND_ROLLS;
> +}
> +
> /*
> * Fully remap all of the file's data fork at once, which is the critical part
> * in achieving atomic behaviour.
> @@ -1036,6 +1058,7 @@ xfs_reflink_end_atomic_cow(
> xfs_fileoff_t end_fsb;
> int error = 0;
> struct xfs_mount *mp = ip->i_mount;
> + struct xfs_trans_res resv = M_RES(mp)->tr_atomic_ioend;
> struct xfs_trans *tp;
> unsigned int resblks;
>
> @@ -1051,7 +1074,15 @@ xfs_reflink_end_atomic_cow(
> resblks = (end_fsb - offset_fsb) *
> XFS_NEXTENTADD_SPACE_RES(mp, 1, XFS_DATA_FORK);
>
> - error = xfs_trans_alloc(mp, &M_RES(mp)->tr_atomic_ioend, resblks, 0,
> + /*
> + * Reserve enough log operations to remap every block of this write
> + * before we take ILOCK, so that no roll below has to wait for grant
> + * space while holding ILOCK.
> + */
> + resv.tr_logcount = xfs_calc_atomic_write_ioend_logcount(mp,
> + end_fsb - offset_fsb, resv.tr_logres);
> +
> + error = xfs_trans_alloc(mp, &resv, resblks, 0,
> XFS_TRANS_RESERVE, &tp);
> if (error)
> return error;
Yeah, I think you're on the right track with the dynamic tr_logcount
changes but I wonder if you want to constrain the max software atomic
write size so that we don't end up with gigantic chains that consume
significant portions of the log for a single write?
Admittedly I see the multi-megabyte atomic write limits and marvel at
how far we've drifted from the original requirements.
--D
diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
index 1c20a7c27aa1bf..2e84544cd22a0a 100644
--- a/fs/xfs/libxfs/xfs_trans_resv.c
+++ b/fs/xfs/libxfs/xfs_trans_resv.c
@@ -1473,6 +1473,10 @@ xfs_calc_max_atomic_write_fsblocks(
struct xfs_mount *mp)
{
const struct xfs_trans_res *resv = &M_RES(mp)->tr_atomic_ioend;
+ const unsigned int max_log_bytes =
+ XFS_FSB_TO_B(mp, mp->m_sb.sb_logblocks * 10 / 4);
+ const unsigned int log_bytes_per_aw_block =
+ (resv->tr_logres * resv->tr_logcount * 5) / 4;
unsigned int per_intent = 0;
unsigned int step_size = 0;
unsigned int ret = 0;
@@ -1483,6 +1487,9 @@ xfs_calc_max_atomic_write_fsblocks(
if (resv->tr_logres >= step_size)
ret = (resv->tr_logres - step_size) / per_intent;
+
+ if (ret > 0 && log_bytes_per_aw_block > max_log_bytes / ret)
+ ret = max_log_bytes / log_bytes_per_aw_block;
}
trace_xfs_calc_max_atomic_write_fsblocks(mp, per_intent, step_size,
prev parent reply other threads:[~2026-09-25 23:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 9:34 [bug report] fstests generic/774 hang again Shin'ichiro Kawasaki
2026-09-15 10:00 ` John Garry
2026-09-15 11:48 ` Shin'ichiro Kawasaki
2026-09-15 14:48 ` John Garry
2026-09-15 14:50 ` Darrick J. Wong
2026-09-15 15:41 ` John Garry
2026-09-16 10:23 ` John Garry
2026-09-16 22:23 ` Dave Chinner
2026-09-17 8:28 ` John Garry
2026-09-17 21:20 ` Dave Chinner
2026-09-17 6:30 ` Shin'ichiro Kawasaki
2026-09-16 2:53 ` Shin'ichiro Kawasaki
2026-09-16 21:45 ` Dave Chinner
2026-09-17 6:52 ` Shin'ichiro Kawasaki
2026-09-17 10:45 ` Shin'ichiro Kawasaki
2026-09-17 21:24 ` Dave Chinner
2026-09-19 11:53 ` Shin'ichiro Kawasaki
2026-09-21 22:05 ` Dave Chinner
2026-09-25 1:32 ` Shin'ichiro Kawasaki
2026-09-27 21:30 ` Dave Chinner
2026-09-28 2:45 ` Darrick J. Wong
2026-09-22 0:28 ` Darrick J. Wong
2026-09-25 1:38 ` Shin'ichiro Kawasaki
2026-09-25 23:03 ` Darrick J. Wong [this message]
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=20260925230329.GE2705364@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=dgc@kernel.org \
--cc=john.garry@linux.dev \
--cc=linux-xfs@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
/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