From: "Darrick J. Wong" <djwong@kernel.org>
To: Yuto Ohnuki <ytohnuki@amazon.com>
Cc: Carlos Maiolino <cem@kernel.org>,
Dave Chinner <dchinner@redhat.com>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Brian Foster <bfoster@redhat.com>,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v3 2/4] xfs: refactor xfsaild_push loop into helper
Date: Mon, 9 Mar 2026 09:14:27 -0700 [thread overview]
Message-ID: <20260309161427.GB6033@frogsfrogsfrogs> (raw)
In-Reply-To: <20260308182804.33127-8-ytohnuki@amazon.com>
On Sun, Mar 08, 2026 at 06:28:07PM +0000, Yuto Ohnuki wrote:
> Factor the loop body of xfsaild_push() into a separate
> xfsaild_process_logitem() helper to improve readability.
>
> This is a pure code movement with no functional change. The
> subsequent patch to fix a use-after-free in the AIL push path
> depends on this refactoring.
>
> Cc: <stable@vger.kernel.org> # v5.9
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
Seems like a reasonable hoist to reduce the length of the function, but
in ordering the patches this way (cleanup, then bugfixes) the hoist also
has to be backported to 5.10/5.15/6.1/6.6/6.12/6.18/6.19.
--D
> ---
> fs/xfs/xfs_trans_ail.c | 116 +++++++++++++++++++++++------------------
> 1 file changed, 64 insertions(+), 52 deletions(-)
>
> diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c
> index 923729af4206..ac747804e1d6 100644
> --- a/fs/xfs/xfs_trans_ail.c
> +++ b/fs/xfs/xfs_trans_ail.c
> @@ -458,6 +458,69 @@ xfs_ail_calc_push_target(
> return target_lsn;
> }
>
> +static void
> +xfsaild_process_logitem(
> + struct xfs_ail *ailp,
> + struct xfs_log_item *lip,
> + xfs_lsn_t lsn,
> + int *stuck,
> + int *flushing)
> +{
> + struct xfs_mount *mp = ailp->ail_log->l_mp;
> + int lock_result;
> +
> + /*
> + * Note that iop_push may unlock and reacquire the AIL lock. We
> + * rely on the AIL cursor implementation to be able to deal with
> + * the dropped lock.
> + */
> + lock_result = xfsaild_push_item(ailp, lip);
> + switch (lock_result) {
> + case XFS_ITEM_SUCCESS:
> + XFS_STATS_INC(mp, xs_push_ail_success);
> + trace_xfs_ail_push(lip);
> +
> + ailp->ail_last_pushed_lsn = lsn;
> + break;
> +
> + case XFS_ITEM_FLUSHING:
> + /*
> + * The item or its backing buffer is already being
> + * flushed. The typical reason for that is that an
> + * inode buffer is locked because we already pushed the
> + * updates to it as part of inode clustering.
> + *
> + * We do not want to stop flushing just because lots
> + * of items are already being flushed, but we need to
> + * re-try the flushing relatively soon if most of the
> + * AIL is being flushed.
> + */
> + XFS_STATS_INC(mp, xs_push_ail_flushing);
> + trace_xfs_ail_flushing(lip);
> +
> + (*flushing)++;
> + ailp->ail_last_pushed_lsn = lsn;
> + break;
> +
> + case XFS_ITEM_PINNED:
> + XFS_STATS_INC(mp, xs_push_ail_pinned);
> + trace_xfs_ail_pinned(lip);
> +
> + (*stuck)++;
> + ailp->ail_log_flush++;
> + break;
> + case XFS_ITEM_LOCKED:
> + XFS_STATS_INC(mp, xs_push_ail_locked);
> + trace_xfs_ail_locked(lip);
> +
> + (*stuck)++;
> + break;
> + default:
> + ASSERT(0);
> + break;
> + }
> +}
> +
> static long
> xfsaild_push(
> struct xfs_ail *ailp)
> @@ -505,62 +568,11 @@ xfsaild_push(
>
> lsn = lip->li_lsn;
> while ((XFS_LSN_CMP(lip->li_lsn, ailp->ail_target) <= 0)) {
> - int lock_result;
>
> if (test_bit(XFS_LI_FLUSHING, &lip->li_flags))
> goto next_item;
>
> - /*
> - * Note that iop_push may unlock and reacquire the AIL lock. We
> - * rely on the AIL cursor implementation to be able to deal with
> - * the dropped lock.
> - */
> - lock_result = xfsaild_push_item(ailp, lip);
> - switch (lock_result) {
> - case XFS_ITEM_SUCCESS:
> - XFS_STATS_INC(mp, xs_push_ail_success);
> - trace_xfs_ail_push(lip);
> -
> - ailp->ail_last_pushed_lsn = lsn;
> - break;
> -
> - case XFS_ITEM_FLUSHING:
> - /*
> - * The item or its backing buffer is already being
> - * flushed. The typical reason for that is that an
> - * inode buffer is locked because we already pushed the
> - * updates to it as part of inode clustering.
> - *
> - * We do not want to stop flushing just because lots
> - * of items are already being flushed, but we need to
> - * re-try the flushing relatively soon if most of the
> - * AIL is being flushed.
> - */
> - XFS_STATS_INC(mp, xs_push_ail_flushing);
> - trace_xfs_ail_flushing(lip);
> -
> - flushing++;
> - ailp->ail_last_pushed_lsn = lsn;
> - break;
> -
> - case XFS_ITEM_PINNED:
> - XFS_STATS_INC(mp, xs_push_ail_pinned);
> - trace_xfs_ail_pinned(lip);
> -
> - stuck++;
> - ailp->ail_log_flush++;
> - break;
> - case XFS_ITEM_LOCKED:
> - XFS_STATS_INC(mp, xs_push_ail_locked);
> - trace_xfs_ail_locked(lip);
> -
> - stuck++;
> - break;
> - default:
> - ASSERT(0);
> - break;
> - }
> -
> + xfsaild_process_logitem(ailp, lip, lsn, &stuck, &flushing);
> count++;
>
> /*
> --
> 2.50.1
>
>
>
>
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
>
> Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
>
>
>
>
next prev parent reply other threads:[~2026-03-09 16:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 18:28 [PATCH v3 0/4] xfs: fix AIL push use-after-free during shutdown Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 1/4] xfs: stop reclaim before pushing AIL during unmount Yuto Ohnuki
2026-03-09 16:02 ` Darrick J. Wong
2026-03-10 17:33 ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 2/4] xfs: refactor xfsaild_push loop into helper Yuto Ohnuki
2026-03-09 16:14 ` Darrick J. Wong [this message]
2026-03-10 17:38 ` Yuto Ohnuki
2026-03-10 5:26 ` Dave Chinner
2026-03-10 17:46 ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 3/4] xfs: avoid dereferencing log items after push callbacks Yuto Ohnuki
2026-03-09 16:27 ` Darrick J. Wong
2026-03-10 5:25 ` Dave Chinner
2026-03-10 17:51 ` Yuto Ohnuki
2026-03-10 5:27 ` Dave Chinner
2026-03-10 17:56 ` Yuto Ohnuki
2026-03-08 18:28 ` [PATCH v3 4/4] xfs: save ailp before dropping the AIL lock in " Yuto Ohnuki
2026-03-09 16:28 ` Darrick J. Wong
2026-03-10 5:27 ` Dave Chinner
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=20260309161427.GB6033@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=darrick.wong@oracle.com \
--cc=dchinner@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=ytohnuki@amazon.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 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.