Re: [PATCH 3/5] btrfs: handle ENOENT in btrfs_uuid_tree_iterate

From: Filipe Manana <fdmanana@gmail.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>, kernel-team@fb.com
Subject: Re: [PATCH 3/5] btrfs: handle ENOENT in btrfs_uuid_tree_iterate
Date: Fri, 6 Dec 2019 15:13:21 +0000	[thread overview]
Message-ID: <CAL3q7H6BfCF1fN8Wtn=k2-oWFoqojiGjkKZ5q2O=wWXbuEyfYg@mail.gmail.com> (raw)
In-Reply-To: <20191206143718.167998-4-josef@toxicpanda.com>

On Fri, Dec 6, 2019 at 2:38 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> If we get an -ENOENT back from btrfs_uuid_iter_rem when iterating the
> uuid tree we'll just continue and do btrfs_next_item().  However we've
> done a btrfs_release_path() at this point and no longer have a valid
> path.  So increment the key and go back and do a normal search.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
>  fs/btrfs/uuid-tree.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/uuid-tree.c b/fs/btrfs/uuid-tree.c
> index 91caab63bdf5..8871e0bb3b69 100644
> --- a/fs/btrfs/uuid-tree.c
> +++ b/fs/btrfs/uuid-tree.c
> @@ -324,6 +324,8 @@ int btrfs_uuid_tree_iterate(struct btrfs_fs_info *fs_info,
>                                 }
>                                 if (ret < 0 && ret != -ENOENT)
>                                         goto out;
> +                               key.objectid++;

Why not key.offset++ instead?
By incrementing the objectid it seems we can skip the key for another
subvolume with an uuid having the same value for its first 8 bytes as
the current one, no?

thanks

> +                               goto again_search_slot;
>                         }
>                         item_size -= sizeof(subid_le);
>                         offset += sizeof(subid_le);
> --
> 2.23.0
>

-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”