[3/5] btrfs: handle ENOENT in btrfs_uuid_tree_iterate
diff mbox series

Message ID 20191206143718.167998-4-josef@toxicpanda.com
State New
Headers show
Series
  • Various fixes
Related show

Commit Message

Josef Bacik Dec. 6, 2019, 2:37 p.m. UTC
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(+)

Comments

Filipe Manana Dec. 6, 2019, 3:13 p.m. UTC | #1
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
>
Josef Bacik Dec. 6, 2019, 3:17 p.m. UTC | #2
On Fri, Dec 06, 2019 at 03:13:21PM +0000, Filipe Manana wrote:
> 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?

Oops you're right, I had it in my head the objectid was the subvolid.  I'll fix
this, thanks,

Josef

Patch
diff mbox series

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++;
+				goto again_search_slot;
 			}
 			item_size -= sizeof(subid_le);
 			offset += sizeof(subid_le);