your patch "crypto: api - Fix built-in testing dependency failures"

your patch "crypto: api - Fix built-in testing dependency failures"

[Jan Beulich]

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?

Thanks, Jan

Re: your patch "crypto: api - Fix built-in testing dependency failures"

[Herbert Xu]

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?

Can you send me your .config file please?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] crypto: api - Move cryptomgr soft dependency into algapi

[Herbert Xu]

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@suse.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 9f15e11f5d73..79db3e461543 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -1330,3 +1330,4 @@ module_exit(crypto_algapi_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Cryptographic algorithms API");
+MODULE_SOFTDEP("pre: cryptomgr");
diff --git a/crypto/api.c b/crypto/api.c
index cf0869dd130b..7ddfe946dd56 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -643,4 +643,3 @@ EXPORT_SYMBOL_GPL(crypto_req_done);
 
 MODULE_DESCRIPTION("Cryptographic core API");
 MODULE_LICENSE("GPL");
-MODULE_SOFTDEP("pre: cryptomgr");
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: api - Move cryptomgr soft dependency into algapi

[Jan Beulich]

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@suse.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Looks like it does (unless I've screwed up with removing the workaround
I had to put in place):
Tested-by: Jan Beulich <jbeulich@suse.com>

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