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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt