linux-kernel - Re: [PATCH v2] btrfs: reduce chunk_map lookups in btrfs_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL3q7H7R-AHyhz3pNMpAaqR6QKquGmCudOXco7BJ8QY4qA6naw@mail.gmail.com>
Date: Tue, 13 Aug 2024 12:07:53 +0100
From: Filipe Manana <fdmanana@...nel.org>
To: Johannes Thumshirn <Johannes.Thumshirn@....com>
Cc: Johannes Thumshirn <jth@...nel.org>, Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, 
	David Sterba <dsterba@...e.com>, 
	"open list:BTRFS FILE SYSTEM" <linux-btrfs@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	Qu Wenruo <wqu@...e.com>
Subject: Re: [PATCH v2] btrfs: reduce chunk_map lookups in btrfs_map_block

On Tue, Aug 13, 2024 at 12:05 PM Johannes Thumshirn
<Johannes.Thumshirn@....com> wrote:
>
> On 13.08.24 12:57, Filipe Manana wrote:
> > On Tue, Aug 13, 2024 at 11:49 AM Johannes Thumshirn <jth@...nel.org> wrote:
> >>
> >> From: Johannes Thumshirn <johannes.thumshirn@....com>
> >>
> >> Currently we're calling btrfs_num_copies() before btrfs_get_chunk_map() in
> >> btrfs_map_block(). But btrfs_num_copies() itself does a chunk map lookup
> >> to be able to calculate the number of copies.
> >>
> >> So split out the code getting the number of copies from btrfs_num_copies()
> >> into a helper called btrfs_chunk_map_num_copies() and directly call it
> >> from btrfs_map_block() and btrfs_num_copies().
> >>
> >> This saves us one rbtree lookup per btrfs_map_block() invocation.
> >>
> >> Reviewed-by: Qu Wenruo <wqu@...e.com>
> >> Reviewed-by: Filipe Manana <fdmanana@...e.com>
> >> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@....com>
> >> ---
> >> Changes in v2:
> >> - Added Reviewed-bys
> >> - Reflowed comments
> >> - Moved non RAID56 cases to the end without an if
> >> Link to v1:
> >> https://lore.kernel.org/all/20240812165931.9106-1-jth@kernel.org/
> >>
> >>   fs/btrfs/volumes.c | 58 +++++++++++++++++++++++++---------------------
> >>   1 file changed, 32 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> >> index e07452207426..796f6350a017 100644
> >> --- a/fs/btrfs/volumes.c
> >> +++ b/fs/btrfs/volumes.c
> >> @@ -5781,38 +5781,44 @@ void btrfs_mapping_tree_free(struct btrfs_fs_info *fs_info)
> >>          write_unlock(&fs_info->mapping_tree_lock);
> >>   }
> >>
> >> +static int btrfs_chunk_map_num_copies(struct btrfs_chunk_map *map)
> >
> > Same as commented before, can be const.
>
> No it can't:
> fs/btrfs/volumes.c:5784:8: warning: type qualifiers ignored on function
> return type [-Wignored-qualifiers]
>   5784 | static const int btrfs_chunk_map_num_copies(struct
> btrfs_chunk_map *map)
>
> Or did you mean the const struct btrfs_chunk_map? That could be done but
> I don't see a reason.

Yes, I meant const for the argument, not the return type.
It's not needed but it makes it clear for a reader that we don't
intend to change anything. It's just a best practice.

>
> >
> >> +{
> >> +       enum btrfs_raid_types index = btrfs_bg_flags_to_raid_index(map->type);
> >> +
> >> +       if (map->type & BTRFS_BLOCK_GROUP_RAID5)
> >> +               return 2;
> >> +
> >> +       /*
> >> +        * There could be two corrupted data stripes, we need to loop
> >> +        * retry in order to rebuild the correct data.
> >> +        *
> >> +        * Fail a stripe at a time on every retry except the stripe
> >> +        * under reconstruction.
> >> +        */
> >> +       if (map->type & BTRFS_BLOCK_GROUP_RAID6)
> >> +               return map->num_stripes;
> >> +
> >> +       /* Non-RAID56, use their ncopies from btrfs_raid_array. */
> >> +       return btrfs_raid_array[index].ncopies;
> >> +}
> >> +
> >>   int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 logical, u64 len)
> >>   {
> >>          struct btrfs_chunk_map *map;
> >> -       enum btrfs_raid_types index;
> >> -       int ret = 1;
> >> +       int ret;
> >>
> >>          map = btrfs_get_chunk_map(fs_info, logical, len);
> >>          if (IS_ERR(map))
> >>                  /*
> >> -                * We could return errors for these cases, but that could get
> >> -                * ugly and we'd probably do the same thing which is just not do
> >> -                * anything else and exit, so return 1 so the callers don't try
> >> -                * to use other copies.
> >> +                * We could return errors for these cases, but that
> >> +                * could get ugly and we'd probably do the same thing
> >> +                * which is just not do anything else and exit, so
> >> +                * return 1 so the callers don't try to use other
> >> +                * copies.
> >
> > My previous comment about reformatting was just for the comment that
> > was moved, the one now inside btrfs_chunk_map_num_copies().
> > For this one I don't think we should do it, as we aren't moving it
> > around or changing its content.
> >
> > It's just confusing to have this sort of unrelated change mixed in.
> >
>
> Whoops that was fat fingered somehow.
>