On 02.02.2022 07:46, Herbert Xu wrote:
> On Mon, Jan 31, 2022 at 04:30:06PM +0100, Jan Beulich wrote:
>> Herbert,
>>
>> unexpectedly after updating to 5.16 on one of my systems (the 1st one
>> I tried) btrfs.ko would not load anymore. Since this did happen before,
>> I inspected module dependencies, but they were all fine. Nevertheless
>> it was libcrc32c.ko which actually failed to load, but the error
>> ("Accessing a corrupted shared library") wasn't very helpful. Until I
>> spotted crypto_alg_lookup(), and "only" a few steps I found this commit
>> of yours. The problem, ultimately, is that all of the sudden
>> cryptomgr.ko needs to be available in initrd. Without any module having
>> a dependency on it, it wouldn't get pulled in automatically. And there
>> was no need for it before (until later in the boot process, when / was
>> already mounted).
>>
>> Can this be addressed in some way, i.e. is there a way to re-work your
>> change to remove the dependency again?
>
> Does this patch help?
>
> ---8<---
> The soft dependency on cryptomgr is only needed in algapi because
> if algapi isn't present then no algorithms can be loaded. This
> also fixes the case where api is built-in but algapi is built as
> a module as the soft dependency would otherwise get lost.
>
> Fixes: 8ab23d547f65 ("crypto: api - Add softdep on cryptomgr")
> Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
> Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Looks like it does (unless I've screwed up with removing the workaround
I had to put in place):
Tested-by: Jan Beulich <jbeulich@xxxxxxxx>
To answer your other reply, I guess the crucial settings you were after
are
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=m
CONFIG_CRYPTO_ALGAPI2=m
Thanks for the quick fixing of the issue,
Jan
