linux-kernel - Re: [PATCH 1/4] btrfs: use BTRFS_PATH_AUTO_FREE in insert_balance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPjX3FepgZqXJ5B1V2Msg4pZHjphqUTRR1K3w=RGeDWzVxaUCA@mail.gmail.com>
Date: Tue, 8 Apr 2025 20:00:30 +0200
From: Daniel Vacek <neelx@...e.com>
To: Filipe Manana <fdmanana@...nel.org>
Cc: Yangtao Li <frank.li@...o.com>, clm@...com, josef@...icpanda.com, dsterba@...e.com, 
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] btrfs: use BTRFS_PATH_AUTO_FREE in insert_balance_item()

On Tue, 8 Apr 2025 at 19:52, Filipe Manana <fdmanana@...nel.org> wrote:
>
> On Tue, Apr 8, 2025 at 6:47 PM Daniel Vacek <neelx@...e.com> wrote:
> >
> > On Tue, 8 Apr 2025 at 19:41, Filipe Manana <fdmanana@...nel.org> wrote:
> > >
> > > On Tue, Apr 8, 2025 at 6:36 PM Daniel Vacek <neelx@...e.com> wrote:
> > > >
> > > > On Tue, 8 Apr 2025 at 16:47, Filipe Manana <fdmanana@...nel.org> wrote:
> > > > >
> > > > > On Tue, Apr 8, 2025 at 1:18 PM Yangtao Li <frank.li@...o.com> wrote:
> > > > > >
> > > > > > All cleanup paths lead to btrfs_path_free so we can define path with the
> > > > > > automatic free callback.
> > > > > >
> > > > > > Signed-off-by: Yangtao Li <frank.li@...o.com>
> > > > > > ---
> > > > > >  fs/btrfs/volumes.c | 7 ++-----
> > > > > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > > > > > index c8c21c55be53..a962efaec4ea 100644
> > > > > > --- a/fs/btrfs/volumes.c
> > > > > > +++ b/fs/btrfs/volumes.c
> > > > > > @@ -3730,7 +3730,7 @@ static int insert_balance_item(struct btrfs_fs_info *fs_info,
> > > > > >         struct btrfs_trans_handle *trans;
> > > > > >         struct btrfs_balance_item *item;
> > > > > >         struct btrfs_disk_balance_args disk_bargs;
> > > > > > -       struct btrfs_path *path;
> > > > > > +       BTRFS_PATH_AUTO_FREE(path);
> > > > > >         struct extent_buffer *leaf;
> > > > > >         struct btrfs_key key;
> > > > > >         int ret, err;
> > > > > > @@ -3740,10 +3740,8 @@ static int insert_balance_item(struct btrfs_fs_info *fs_info,
> > > > > >                 return -ENOMEM;
> > > > > >
> > > > > >         trans = btrfs_start_transaction(root, 0);
> > > > > > -       if (IS_ERR(trans)) {
> > > > > > -               btrfs_free_path(path);
> > > > > > +       if (IS_ERR(trans))
> > > > > >                 return PTR_ERR(trans);
> > > > > > -       }
> > > > > >
> > > > > >         key.objectid = BTRFS_BALANCE_OBJECTID;
> > > > > >         key.type = BTRFS_TEMPORARY_ITEM_KEY;
> > > > > > @@ -3767,7 +3765,6 @@ static int insert_balance_item(struct btrfs_fs_info *fs_info,
> > > > > >         btrfs_set_balance_sys(leaf, item, &disk_bargs);
> > > > > >         btrfs_set_balance_flags(leaf, item, bctl->flags);
> > > > > >  out:
> > > > > > -       btrfs_free_path(path);
> > > > > >         err = btrfs_commit_transaction(trans);
> > > > >
> > > > > This isn't a good idea at all.
> > > > > We're now committing a transaction while holding a write lock on some
> > > > > leaf of the tree root - this can result in a deadlock as the
> > > > > transaction commit needs to update the tree root (see
> > > > > update_cowonly_root()).
> > > >
> > > > I do not follow. This actually looks good to me.
> > >
> > > path->nodes[0] has a write locked leaf, returned by btrfs_insert_empty_item().
> >
> > Well, the first return is before calling this function and the final
> > return is only after committing.
> >
> > Again, the function keeps it's former structure as it was before this
> > patch. I still don't see any logical or functional change.
>
> I don't know how to put it simpler to you. There's a path setup by
> btrfs_insert_empty_item(), with a leaf locked in write mode.
> You can't just do a transaction commit while holding it locked, as
> this can deadlock because updating the tree root is part of the
> critical section of a transaction commit.
> It seems trivial to me...

Nah, of course. I see. Simply put the btrfs_free_path() needs to be
called before btrfs_commit_transaction() due to need to
btrfs_tree_unlock_rw() in btrfs_release_path() first.

So the sequence matters. The path implicit destructor on return from
insert_balance_item() is only called too late.

Thanks for the details.

> >
> > I'm lost. This still looks to me just as a straightforward cleanup.
> >
> > > > Is there really any functional change? What am I missing?
> > >
> > > Yes there is, a huge one. Even if a transaction commit didn't need to
> > > update the root tree, it would be performance wise to commit a
> > > transaction while holding a lock on a leaf unnecessarily.
> > >
> > > >
> > > > --nX
> > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > > >         if (err && !ret)
> > > > > >                 ret = err;
> > > > > > --
> > > > > > 2.39.0
> > > > > >
> > > > > >
> > > > >