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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1780 bytes --]



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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]