public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Sun YangKai <sunk67188@gmail.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, sunk67188@gmail.com
Subject: Re: [PATCH 2/2] btrfs: more trivial BTRFS_PATH_AUTO_FREE conversions
Date: Fri, 22 Aug 2025 21:08:37 +0800	[thread overview]
Message-ID: <877947289.0ifERbkFSE@saltykitkat> (raw)
In-Reply-To: <20250822130123.GV22430@twin.jikos.cz>

> On Thu, Aug 21, 2025 at 09:12:24PM +0800, Sun YangKai wrote:
> > Trival pattern for the auto freeing with goto -> return convertions
> > if possible. No other function cleanup.
> 
> Not all the changes match the trivial pattern described in the patches.
> 
> > Signed-off-by: Sun YangKai <sunk67188@gmail.com>
> > ---
> > 
> >  fs/btrfs/raid-stripe-tree.c |  16 +-
> >  fs/btrfs/ref-verify.c       |   3 +-
> >  fs/btrfs/reflink.c          |   3 +-
> >  fs/btrfs/relocation.c       |  66 +++-----
> >  fs/btrfs/root-tree.c        |  49 +++---
> >  fs/btrfs/scrub.c            |  11 +-
> >  fs/btrfs/send.c             | 307 +++++++++++++-----------------------
> >  fs/btrfs/super.c            |   9 +-
> >  fs/btrfs/tree-log.c         | 124 +++++----------
> >  9 files changed, 204 insertions(+), 384 deletions(-)
> > 
> > diff --git a/fs/btrfs/raid-stripe-tree.c b/fs/btrfs/raid-stripe-tree.c
> > index cab0b291088c..231107cafab2 100644
> > --- a/fs/btrfs/raid-stripe-tree.c
> > +++ b/fs/btrfs/raid-stripe-tree.c
> > @@ -67,7 +67,7 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle
> > *trans, u64 start, u64 le> 
> >  {
> >  
> >  	struct btrfs_fs_info *fs_info = trans->fs_info;
> >  	struct btrfs_root *stripe_root = fs_info->stripe_root;
> > 
> > -	struct btrfs_path *path;
> > +	BTRFS_PATH_AUTO_FREE(path);
> > 
> >  	struct btrfs_key key;
> >  	struct extent_buffer *leaf;
> >  	u64 found_start;
> > 
> > @@ -260,7 +260,6 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle
> > *trans, u64 start, u64 le> 
> >  		btrfs_release_path(path);
> >  	
> >  	}
> > 
> > -	btrfs_free_path(path);
> > 
> >  	return ret;
> >  
> >  }
> 
> As an example, this is the pattern, just declare, allocate and free at
> the end.
> 
> > @@ -376,7 +374,7 @@ int btrfs_get_raid_extent_offset(struct btrfs_fs_info
> > *fs_info,> 
> >  	struct btrfs_stripe_extent *stripe_extent;
> >  	struct btrfs_key stripe_key;
> >  	struct btrfs_key found_key;
> > 
> > -	struct btrfs_path *path;
> > +	BTRFS_PATH_AUTO_FREE(path);
> > 
> >  	struct extent_buffer *leaf;
> >  	const u64 end = logical + *length;
> >  	int num_stripes;
> > 
> > @@ -402,7 +400,7 @@ int btrfs_get_raid_extent_offset(struct btrfs_fs_info
> > *fs_info,> 
> >  	ret = btrfs_search_slot(NULL, stripe_root, &stripe_key, path, 0, 0);
> >  	if (ret < 0)
> > 
> > -		goto free_path;
> > +		return ret;
> > 
> >  	if (ret) {
> >  	
> >  		if (path->slots[0] != 0)
> >  		
> >  			path->slots[0]--;
> > 
> > @@ -459,8 +457,7 @@ int btrfs_get_raid_extent_offset(struct btrfs_fs_info
> > *fs_info,> 
> >  		trace_btrfs_get_raid_extent_offset(fs_info, logical, *length,
> >  		
> >  						   stripe->physical, devid);
> > 
> > -		ret = 0;
> > -		goto free_path;
> > +		return 0;
> > 
> >  	}
> >  	
> >  	/* If we're here, we haven't found the requested devid in the stripe. 
*/
> > 
> > @@ -474,8 +471,5 @@ int btrfs_get_raid_extent_offset(struct btrfs_fs_info
> > *fs_info,> 
> >  			  logical, logical + *length, stripe->dev->devid,
> >  			  btrfs_bg_type_to_raid_name(map_type));
> >  	
> >  	}
> > 
> > -free_path:
> > -	btrfs_free_path(path);
> > -
> > 
> >  	return ret;
> >  
> >  }
> 
> This is also still trivial with the goto/return conversion as long as
> there's not additional logic around that.
> 
> > diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> > index 7256f6748c8f..8b08d6e4cb2b 100644
> > --- a/fs/btrfs/relocation.c
> > +++ b/fs/btrfs/relocation.c
> > @@ -409,7 +409,7 @@ static noinline_for_stack struct btrfs_backref_node
> > *build_backref_tree(> 
> >  	struct btrfs_backref_iter *iter;
> >  	struct btrfs_backref_cache *cache = &rc->backref_cache;
> >  	/* For searching parent of TREE_BLOCK_REF */
> > 
> > -	struct btrfs_path *path;
> > +	BTRFS_PATH_AUTO_FREE(path);
> > 
> >  	struct btrfs_backref_node *cur;
> >  	struct btrfs_backref_node *node = NULL;
> >  	struct btrfs_backref_edge *edge;
> > 
> > @@ -461,7 +461,6 @@ static noinline_for_stack struct btrfs_backref_node
> > *build_backref_tree(> 
> >  out:
> >  	btrfs_free_path(iter->path);
> >  	kfree(iter);
> > 
> > -	btrfs_free_path(path);
> 
> In this case it depends, there are a few more statements after the
> freeing which means the path is still allocated until the function ends.
> If the statements are something quick, like in this case then it's still
> OK and considered trivial.
> 
> >  	if (ret) {
> >  	
> >  		btrfs_backref_error_cleanup(cache, node);
> >  		return ERR_PTR(ret);
> > 
> > @@ -1661,8 +1651,6 @@ static noinline_for_stack int
> > merge_reloc_root(struct reloc_control *rc,> 
> >  	btrfs_tree_unlock(leaf);
> >  	free_extent_buffer(leaf);
> >  
> >  out:
> > -	btrfs_free_path(path);
> 
> Similar to the previous one but is not trivial, due to calls to
> insert_dirty_subvol(), btrfs_end_transaction_throttle(),
> btrfs_btree_balance_dirty() and invalidate_extent_cache(). Please have a
> look what the functions do.
> 
> > -
> > 
> >  	if (ret == 0) {
> >  	
> >  		ret = insert_dirty_subvol(trans, rc, root);
> >  		if (ret)
> > 
> > @@ -4080,7 +4058,7 @@ int btrfs_recover_relocation(struct btrfs_fs_info
> > *fs_info)> 
> >  	struct btrfs_key key;
> >  	struct btrfs_root *fs_root;
> >  	struct btrfs_root *reloc_root;
> > 
> > -	struct btrfs_path *path;
> > +	BTRFS_PATH_AUTO_FREE(path);
> > 
> >  	struct extent_buffer *leaf;
> >  	struct reloc_control *rc = NULL;
> >  	struct btrfs_trans_handle *trans;
> > 
> > @@ -4229,8 +4207,6 @@ int btrfs_recover_relocation(struct btrfs_fs_info
> > *fs_info)> 
> >  out:
> >  	free_reloc_roots(&reloc_roots);
> > 
> > -	btrfs_free_path(path);
> 
> Same non-trivial case, there's btrfs_orphan_cleanup() after that.
> 
> > -
> > 
> >  	if (ret == 0) {
> >  	
> >  		/* cleanup orphan inode in data relocation tree */
> >  		fs_root = btrfs_grab_root(fs_info->data_reloc_root);
> 
> Please split the patch to parts that have the described trivial changes,
> and then one patch per function in case it's not trivial and needs some
> adjustments.
> 
> The freeing followed by other code can be still converted to auto
> cleaning but there must be an explicit path = NULL after the free.

Got it. Thank you for your patience and kind reply. I'll go over those changes 
again.

Best regards,
Sun YangKai




  reply	other threads:[~2025-08-22 13:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21 13:12 [PATCH v2 0/2] btrfs: more trivial BTRFS_PATH_AUTO_FREE conversions Sun YangKai
2025-08-21 13:12 ` [PATCH 1/2] btrfs: get_inode_info(): check NULL info parameter early Sun YangKai
2025-08-22 12:50   ` David Sterba
2025-08-22 12:58     ` Sun YangKai
2025-08-30  7:00   ` kernel test robot
2025-08-21 13:12 ` [PATCH 2/2] btrfs: more trivial BTRFS_PATH_AUTO_FREE conversions Sun YangKai
2025-08-22 13:01   ` David Sterba
2025-08-22 13:08     ` Sun YangKai [this message]
2025-08-22 15:51     ` Sun YangKai
2025-08-26 16:56       ` David Sterba
2025-08-27 12:24         ` Sun YangKai
2025-08-29  0:02           ` David Sterba

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=877947289.0ifERbkFSE@saltykitkat \
    --to=sunk67188@gmail.com \
    --cc=dsterba@suse.cz \
    --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