From: Boris Burkov <boris@bur.io>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/3] btrfs: fix barrier usage in btrfs_record_root_in_trans()
Date: Fri, 18 Sep 2026 10:36:55 -0700 [thread overview]
Message-ID: <20260918173655.GC2900089@zen.localdomain> (raw)
In-Reply-To: <ded35d39b9858ee6f20ee3358a8e592a36e8e33c.1789734246.git.fdmanana@suse.com>
On Fri, Sep 18, 2026 at 01:28:10PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> The barrier usage in btrfs_record_root_in_trans() is wrong, as the writer
> side, in record_root_in_trans(), sets BTRFS_ROOT_IN_TRANS_SETUP, does a
> write barrier and then sets the root's last transaction. This means the
> reader side must check the root's last transaction, issue a read barrier
> and then check for BTRFS_ROOT_IN_TRANS_SETUP. However, currently we issue
> a read barrier and then check the root's last transaction and the bit
> BTRFS_ROOT_IN_TRANS_SETUP, which can be problematic because the CPU is
> free to reorder the checks and the following can happen:
>
> 1) Before reading the root's last_trans, it checks that
> BTRFS_ROOT_IN_TRANS_SETUP is not set.
>
> 2) A writer sets BTRFS_ROOT_IN_TRANS_SETUP, does smp_wmb() and updates
> the root's last_trans.
>
> 3) The reader then sees the root's last_trans matches the current
> transaction and falsely concludes the root setup is completes and
> returns without waiting for the writer task to complete the setup
> (calling btrfs_init_reloc_root()).
>
> So fix the reading ordered as previously described: check the root's
> last_trans, issue read barrier and then check BTRFS_ROOT_IN_TRANS_SETUP
> (the reverse of what the writer side does).
I think a comment on why we can't use release/acquire (u64) but that the
non-atomicity is ok (we only check equality?) might be nice. Otherwise
we are supposed to have some code like i_size_read(), right?
Not blocking at all, just an observation, since those helpers are
supposed to prevent this kind of bug.
>
> Assisted-by: LLM
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
> fs/btrfs/transaction.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> index c1555621ae4e..13203ea9e116 100644
> --- a/fs/btrfs/transaction.c
> +++ b/fs/btrfs/transaction.c
> @@ -511,10 +511,11 @@ int btrfs_record_root_in_trans(struct btrfs_trans_handle *trans,
> * see record_root_in_trans for comments about IN_TRANS_SETUP usage
> * and barriers
> */
> - smp_rmb();
> - if (btrfs_get_root_last_trans(root) == trans->transid &&
> - !test_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state))
> - return 0;
> + if (btrfs_get_root_last_trans(root) == trans->transid) {
> + smp_rmb();
> + if (!test_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state))
> + return 0;
> + }
>
> mutex_lock(&fs_info->reloc_mutex);
> ret = record_root_in_trans(trans, root, false);
> --
> 2.47.2
>
next prev parent reply other threads:[~2026-09-18 17:36 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
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 [this message]
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=20260918173655.GC2900089@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox