[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL3q7H6sYN_nmqwJb861qm08Fb5hBr_4QrxJCzeq6Quwh04bjA@mail.gmail.com>
Date: Wed, 9 Apr 2025 10:45:09 +0100
From: Filipe Manana <fdmanana@...nel.org>
To: dsterba@...e.cz
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, Apr 8, 2025 at 11:50 PM David Sterba <dsterba@...e.cz> wrote:
>
> On Tue, Apr 08, 2025 at 06:29:30AM -0600, Yangtao Li 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);
>
> The pattern where btrfs_free_path() is not called at the end and is
> followed by other code is probably not worth converting. It would be
> possible to replace it by
>
> btrfs_release_path(path);
> path = NULL;
Should be btrfs_free_path() instead, otherwise it leaks memory.
Or just do the release without setting the path to NULL and leaving
the path auto free.
>
> that drops the locks and refs from the path but this does not save us
> much compared to the straightforward BTRFS_PATH_AUTO_FREE() conversions.
> Also release will still keep the object allocated although we don't need
> it. As a principle, resources, locks and critical sections should be as
> short as possible.
>
> Unfortunatelly I've probably fished all the trivial and almost-trivial
> conversions, we don't want 100% use of BTRFS_PATH_AUTO_FREE(), only when
> it improves the code.
>
> You may still find cases worth converting, the typical pattern is
> btrfs_path_alloc() somewhere near top of the function and
> btrfs_free_path() called right before a return.
>
Powered by blists - more mailing lists