On Tue, Sep 24, 2019 at 04:49:20PM +0200, David Sterba wrote: > On Wed, Sep 11, 2019 at 12:09:29PM -0400, Josef Bacik wrote: > > On Fri, Sep 06, 2019 at 10:15:32AM -0700, Mark Fasheh wrote: > > > From: Mark Fasheh <mfas...@suse.de> > > > > > > build_backref_tree() is walking extent refs in what is an otherwise self > > > contained chunk of code. We can shrink the total number of lines in > > > build_backref_tree() *and* make it more readable by moving that walk into > > > its own subroutine. > > > > > > Signed-off-by: Mark Fasheh <mfas...@suse.de> > > > --- > > > fs/btrfs/backref-cache.c | 110 +++++++++++++++++++++++---------------- > > > 1 file changed, 65 insertions(+), 45 deletions(-) > > > > > > diff --git a/fs/btrfs/backref-cache.c b/fs/btrfs/backref-cache.c > > > index d0f6530f23b8..ff0d49ca6e26 100644 > > > --- a/fs/btrfs/backref-cache.c > > > +++ b/fs/btrfs/backref-cache.c > > > @@ -336,6 +336,61 @@ int find_inline_backref(struct extent_buffer *leaf, > > > int slot, > > > return 0; > > > } > > > > > > +#define SEARCH_COMPLETE 1 > > > +#define SEARCH_NEXT 2 > > > +static int find_next_ref(struct btrfs_root *extent_root, u64 cur_bytenr, > > > + struct btrfs_path *path, unsigned long *ptr, > > > + unsigned long *end, struct btrfs_key *key, bool exist) > > > > I'd rather we do an enum here, so it's clear what we're expecting in the > > code > > context. Thanks, > > The function also returns errors (< 0), so do you mean enum for the > SEARCH_* values only for for the function as well?
Blah I didn't notice that, in that case you can add Reviewed-by: Josef Bacik <jo...@toxicpanda.com> Thanks, Josef
