All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Filipe Manana <fdmanana@kernel.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/3] btrfs: clear BTRFS_ROOT_IN_TRANS_SETUP on early exit from record_root_in_trans()
Date: Fri, 18 Sep 2026 10:48:26 -0700	[thread overview]
Message-ID: <20260918174826.GA2925568@zen.localdomain> (raw)
In-Reply-To: <CAL3q7H4dSDPm5Z3F1qwkFA-omHaCXLtyH5u7BOpkhOqAQ3knKg@mail.gmail.com>

On Fri, Sep 18, 2026 at 06:32:05PM +0100, Filipe Manana wrote:
> On Fri, Sep 18, 2026 at 6:18 PM Boris Burkov <boris@bur.io> wrote:
> >
> > On Fri, Sep 18, 2026 at 01:28:09PM +0100, fdmanana@kernel.org wrote:
> > > From: Filipe Manana <fdmanana@suse.com>
> > >
> > > If we exit early because the transaction that last used the root already
> > > matches the current transaction, we leave the BTRFS_ROOT_IN_TRANS_SETUP
> > > bit set in the root (which we just set right before the exit). While this
> > > does not cause any functional issue, it makes callers of
> > > btrfs_record_root_in_trans() always lock fs_info->reloc_mutex and call
> >
> > I found "always" kind of confusing here. It's until one succeeds and
> > clears the bit right? It kind of makes it sound like it leaks it
> > forever.
> 
> Yes, I can reword the sentence to:
> 
> "While this does not cause any functional issue, it makes callers of
>   btrfs_record_root_in_trans() lock fs_info->reloc_mutex and call
>   record_root_in_trans() for nothing, causing unnecessary lock contention,
>   until one of them clears the bit in record_root_in_trans()."
> 
> Thanks.
> 

That version sounds great!

> >
> > > record_root_in_trans() for nothing, causing unnecessary lock contention.
> > > One caller of btrfs_record_root_in_trans() is start_transaction(), used to
> > > start new transaction or joining an existing one, which is a hot path.
> > >
> > > So clear BTRFS_ROOT_IN_TRANS_SETUP on early exit.
> > >
> > > Assisted-by: LLM
> > > Signed-off-by: Filipe Manana <fdmanana@suse.com>
> > > ---
> > >  fs/btrfs/transaction.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> > > index ca114235bbe1..c1555621ae4e 100644
> > > --- a/fs/btrfs/transaction.c
> > > +++ b/fs/btrfs/transaction.c
> > > @@ -432,6 +432,7 @@ static int record_root_in_trans(struct btrfs_trans_handle *trans,
> > >               spin_lock(&fs_info->fs_roots_radix_lock);
> > >               if (btrfs_get_root_last_trans(root) == trans->transid && !force) {
> > >                       spin_unlock(&fs_info->fs_roots_radix_lock);
> > > +                     clear_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state);
> > >                       return 0;
> > >               }
> > >               radix_tree_tag_set(&fs_info->fs_roots_radix,
> > > --
> > > 2.47.2
> > >

  reply	other threads:[~2026-09-18 17:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 12:28 [PATCH 0/3] btrfs: a couple fixes for record_root_in_trans() fdmanana
2026-09-18 12:28 ` [PATCH 1/3] btrfs: clear BTRFS_ROOT_IN_TRANS_SETUP on early exit from record_root_in_trans() fdmanana
2026-09-18 17:19   ` Boris Burkov
2026-09-18 17:32     ` Filipe Manana
2026-09-18 17:48       ` Boris Burkov [this message]
2026-09-18 21:46   ` Qu Wenruo
2026-09-18 12:28 ` [PATCH 2/3] btrfs: fix barrier usage in btrfs_record_root_in_trans() fdmanana
2026-09-18 17:36   ` Boris Burkov
2026-09-18 17:43     ` Filipe Manana
2026-09-18 17:47       ` Boris Burkov
2026-09-18 18:05         ` Filipe Manana
2026-09-18 18:58           ` Boris Burkov
2026-09-18 12:28 ` [PATCH 3/3] btrfs: assert reloc mutex is held in record_root_in_trans() fdmanana
2026-09-18 21:47   ` Qu Wenruo
2026-09-18 17:38 ` [PATCH 0/3] btrfs: a couple fixes for record_root_in_trans() Boris Burkov

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=20260918174826.GA2925568@zen.localdomain \
    --to=boris@bur.io \
    --cc=fdmanana@kernel.org \
    --cc=linux-btrfs@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.