From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/8] xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc
Date: Tue, 15 Jul 2025 07:54:28 -0700 [thread overview]
Message-ID: <20250715145428.GV2672049@frogsfrogsfrogs> (raw)
In-Reply-To: <20250715122544.1943403-4-hch@lst.de>
On Tue, Jul 15, 2025 at 02:25:36PM +0200, Christoph Hellwig wrote:
> xfs_trans_alloc_empty only shares the very basic transaction structure
> allocation and initialization with xfs_trans_alloc.
>
> Split out a new __xfs_trans_alloc helper for that and otherwise decouple
> xfs_trans_alloc_empty from xfs_trans_alloc.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
That makes sense, especially because all the _empty callsites become so
much cleaner later on...
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> fs/xfs/xfs_trans.c | 52 +++++++++++++++++++++++++---------------------
> 1 file changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
> index 1fddea8d761a..e43f44f62c5f 100644
> --- a/fs/xfs/xfs_trans.c
> +++ b/fs/xfs/xfs_trans.c
> @@ -241,6 +241,28 @@ xfs_trans_reserve(
> return error;
> }
>
> +static struct xfs_trans *
> +__xfs_trans_alloc(
> + struct xfs_mount *mp,
> + uint flags)
> +{
> + struct xfs_trans *tp;
> +
> + ASSERT(!(flags & XFS_TRANS_RES_FDBLKS) || xfs_has_lazysbcount(mp));
> +
> + tp = kmem_cache_zalloc(xfs_trans_cache, GFP_KERNEL | __GFP_NOFAIL);
> + if (!(flags & XFS_TRANS_NO_WRITECOUNT))
> + sb_start_intwrite(mp->m_super);
> + xfs_trans_set_context(tp);
> + tp->t_flags = flags;
> + tp->t_mountp = mp;
> + INIT_LIST_HEAD(&tp->t_items);
> + INIT_LIST_HEAD(&tp->t_busy);
> + INIT_LIST_HEAD(&tp->t_dfops);
> + tp->t_highest_agno = NULLAGNUMBER;
> + return tp;
> +}
> +
> int
> xfs_trans_alloc(
> struct xfs_mount *mp,
> @@ -254,33 +276,16 @@ xfs_trans_alloc(
> bool want_retry = true;
> int error;
>
> + ASSERT(resp->tr_logres > 0);
> +
> /*
> * Allocate the handle before we do our freeze accounting and setting up
> * GFP_NOFS allocation context so that we avoid lockdep false positives
> * by doing GFP_KERNEL allocations inside sb_start_intwrite().
> */
> retry:
> - tp = kmem_cache_zalloc(xfs_trans_cache, GFP_KERNEL | __GFP_NOFAIL);
> - if (!(flags & XFS_TRANS_NO_WRITECOUNT))
> - sb_start_intwrite(mp->m_super);
> - xfs_trans_set_context(tp);
> -
> - /*
> - * Zero-reservation ("empty") transactions can't modify anything, so
> - * they're allowed to run while we're frozen.
> - */
> - WARN_ON(resp->tr_logres > 0 &&
> - mp->m_super->s_writers.frozen == SB_FREEZE_COMPLETE);
> - ASSERT(!(flags & XFS_TRANS_RES_FDBLKS) ||
> - xfs_has_lazysbcount(mp));
> -
> - tp->t_flags = flags;
> - tp->t_mountp = mp;
> - INIT_LIST_HEAD(&tp->t_items);
> - INIT_LIST_HEAD(&tp->t_busy);
> - INIT_LIST_HEAD(&tp->t_dfops);
> - tp->t_highest_agno = NULLAGNUMBER;
> -
> + WARN_ON(mp->m_super->s_writers.frozen == SB_FREEZE_COMPLETE);
> + tp = __xfs_trans_alloc(mp, flags);
> error = xfs_trans_reserve(tp, resp, blocks, rtextents);
> if (error == -ENOSPC && want_retry) {
> xfs_trans_cancel(tp);
> @@ -329,9 +334,8 @@ xfs_trans_alloc_empty(
> struct xfs_mount *mp,
> struct xfs_trans **tpp)
> {
> - struct xfs_trans_res resv = {0};
> -
> - return xfs_trans_alloc(mp, &resv, 0, 0, XFS_TRANS_NO_WRITECOUNT, tpp);
> + *tpp = __xfs_trans_alloc(mp, XFS_TRANS_NO_WRITECOUNT);
> + return 0;
> }
>
> /*
> --
> 2.47.2
>
>
next prev parent reply other threads:[~2025-07-15 14:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 12:25 cleanup transaction allocation Christoph Hellwig
2025-07-15 12:25 ` [PATCH 1/8] xfs: use xfs_trans_reserve_more in xfs_trans_reserve_more_inode Christoph Hellwig
2025-07-15 14:47 ` Darrick J. Wong
2025-07-15 12:25 ` [PATCH 2/8] xfs: don't use xfs_trans_reserve in xfs_trans_reserve_more Christoph Hellwig
2025-07-15 14:49 ` Darrick J. Wong
2025-07-15 15:35 ` Christoph Hellwig
2025-07-15 15:55 ` Darrick J. Wong
2025-07-15 12:25 ` [PATCH 3/8] xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc Christoph Hellwig
2025-07-15 14:54 ` Darrick J. Wong [this message]
2025-07-15 12:25 ` [PATCH 4/8] xfs: don't use xfs_trans_reserve in xfs_trans_roll Christoph Hellwig
2025-07-15 14:59 ` Darrick J. Wong
2025-07-15 12:25 ` [PATCH 5/8] xfs: return the allocated transaction from xfs_trans_alloc_empty Christoph Hellwig
2025-07-15 14:59 ` Darrick J. Wong
2025-07-15 12:25 ` [PATCH 6/8] xfs: return the allocated transaction from xchk_trans_alloc_empty Christoph Hellwig
2025-07-15 14:59 ` Darrick J. Wong
2025-07-15 12:25 ` [PATCH 7/8] xfs: return the allocated transaction from xrep_trans_alloc_hook_dummy Christoph Hellwig
2025-07-15 15:18 ` Darrick J. Wong
2025-07-15 15:36 ` Christoph Hellwig
2025-07-15 12:25 ` [PATCH 8/8] xfs: remove the xlog_ticket_t typedef Christoph Hellwig
2025-07-15 15:18 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2025-07-16 12:43 cleanup transaction allocation v2 Christoph Hellwig
2025-07-16 12:43 ` [PATCH 3/8] xfs: decouple xfs_trans_alloc_empty from xfs_trans_alloc Christoph Hellwig
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=20250715145428.GV2672049@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--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;
as well as URLs for NNTP newsgroup(s).