[v4,0/2] btrfs: iget_path cleanup

Message

Leo Martins Aug. 30, 2024, 8:24 p.m. UTC

Updates from v3:
Previously I allocated a path in btrfs_iget and called btrfs_iget_path
with it. However, Josef pointed out that there is a case in
btrfs_iget_path where the inode was found in cache and no path
allocation was necessary. In this patch series I no longer call
btrfs_iget_path from btrfs_iget, instead I duplicated the code from
btrfs_iget_path with a path allocation.

This patch series is a cleanup of btrfs_iget_path and btrfs_iget. It
moves some cleanup and error handling from btrfs_iget_path into
read_locked_inode. In addition it also removes a conditional path
allocation that occurs in read_locked_inode, instead reworking
btrfs_iget to allocate and free the path.

Leo Martins (2):
  btrfs: push btrfs_iget_path cleanup into btrfs_read_locked_inode
  btrfs:

 fs/btrfs/inode.c | 143 +++++++++++++++++++++++++++--------------------
 1 file changed, 81 insertions(+), 62 deletions(-)

Comments

David Sterba Oct. 29, 2024, 11:53 p.m. UTC | #1

On Fri, Aug 30, 2024 at 01:24:53PM -0700, Leo Martins wrote:
> Updates from v3:
> Previously I allocated a path in btrfs_iget and called btrfs_iget_path
> with it. However, Josef pointed out that there is a case in
> btrfs_iget_path where the inode was found in cache and no path
> allocation was necessary. In this patch series I no longer call
> btrfs_iget_path from btrfs_iget, instead I duplicated the code from
> btrfs_iget_path with a path allocation.
> 
> This patch series is a cleanup of btrfs_iget_path and btrfs_iget. It
> moves some cleanup and error handling from btrfs_iget_path into
> read_locked_inode. In addition it also removes a conditional path
> allocation that occurs in read_locked_inode, instead reworking
> btrfs_iget to allocate and free the path.
> 
> Leo Martins (2):
>   btrfs: push btrfs_iget_path cleanup into btrfs_read_locked_inode
>   btrfs:

I had the two patches in my misc-next, I was not sure about something
that I forgot meanwhile. Removing the conditional parameter is a useful
cleanup.  After a fresh look I moved the patches to for-next with some
minor tweaks. Thanks.