On 2020/1/3 下午11:27, David Sterba wrote: > 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? Yes, that's why I mean. > 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. > Isn't there any mechanism to load the module when necessary? Like loopback, it's only loaded when we first setup loopback device. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
