Re: [PATCH 0/6] btrfs-progs: Fixes for github issues

[David Sterba <dsterba@suse.cz>]

On Fri, Jan 03, 2020 at 08:43:01AM +0800, Qu Wenruo wrote:
> 
> 
> On 2020/1/3 上午1:10, David Sterba wrote:
> > On Wed, Dec 18, 2019 at 09:19:36AM +0800, Qu Wenruo wrote:
> >> There are a new batch of fuzzed images for btrfs-progs. They are all
> >> reported by Ruud van Asseldonk from github.
> >>
> >> Patch 1 will make QA life easier by remove the extra 300s wait time.
> >> Patch 2~5 are all the meat for the fuzzed images.
> >>
> >> Just a kind reminder, mkfs/020 test will fail due to tons of problems:
> >> - Undefined $csum variable
> >> - Undefined $dev1 variable
> > 
> > These are fixed in devel now.
> > 
> >> - Bad kernel probe for support csum
> >>   E.g. if Blake2 not compiled, it still shows up in supported csum algo,
> >>   but will fail to mount.
> > 
> > The list of supported is from the point of view of the filesystem.
> > Providing the module is up to the user.
> 
> IIRC, doing such probe at btrfs module load time would be more user
> friendly though.

I don't understand how you think this could be improved. The list of
algorithms is provided by the filesystem, the implementations are
provided by the crypto subsystem (either compiled in or as modules). Two
different things.

So you mean that at btrfs module load time, all hash algorithms are
probed? What if some of them gets unloaded, or loaded later (so modprobe
won't see it at btrfs load time). This would require keeping the state
up to date and this is out of scope what filesystem should do.