Btrfs devel - Aug 2007 - path may be freed twice in btrfs_read_locked_inode.

hello,

path is freed twice when encounter bad inode, once before goto 
make_bad, once at label make_bad.


--- a/inode.c   Fri Aug 10 16:22:09 2007 -0400
+++ b/inode.c   Mon Aug 20 14:27:03 2007 +0800
@@ -142,8 +142,6 @@ void btrfs_read_locked_inode(struct inod
         return;

  make_bad:
-       btrfs_release_path(root, path);
-       btrfs_free_path(path);
         mutex_unlock(&root->fs_info->fs_mutex);
         make_bad_inode(inode);
  }


The issue was found after I try to create cross subvolume hardlink 
on the fs. I find "forbid cross subvolume renames and hardlinks" is 
the TODO list and feel that it's easy to implement it (check 
BTRFS_I(src)->root ==  BTRFS_I(dest dir)->root). what else need to 
consider? thank you!

YZ

On Mon, 20 Aug 2007 15:36:29 +0800
Yan Zheng <yanzheng@21cn.com> wrote:
> hello,
> 
> path is freed twice when encounter bad inode, once before goto 
> make_bad, once at label make_bad.
> 
> 
> --- a/inode.c   Fri Aug 10 16:22:09 2007 -0400
> +++ b/inode.c   Mon Aug 20 14:27:03 2007 +0800
> @@ -142,8 +142,6 @@ void btrfs_read_locked_inode(struct inod
>          return;
> 
>   make_bad:
> -       btrfs_release_path(root, path);
> -       btrfs_free_path(path);
>          mutex_unlock(&root->fs_info->fs_mutex);
>          make_bad_inode(inode);
>   }
Hi, thanks for looking through things.

It is safe to call btrfs_release_path twice on the same path (although
not really a good idea ;).  The path struct is zeroed after being
released, so the second call will do nothing.

This patch removes the btrfs_free_path line, which will leak the path.
> 
> The issue was found after I try to create cross subvolume hardlink 
> on the fs. I find "forbid cross subvolume renames and hardlinks"
is
> the TODO list and feel that it's easy to implement it (check 
> BTRFS_I(src)->root ==  BTRFS_I(dest dir)->root). what else need to 
> consider? thank you!
That should be enough, it's just a matter of testing it ;)

-chris