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

Qu Wenruo
2020-01-04T01:26:38Z

[-- 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 --]