Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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
> 

  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