| Message ID | 20191206143718.167998-4-josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Various fixes | expand |
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 >
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
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);
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(+)