On Tue, Aug 06, 2024 at 06:35:05PM +0800, Herbert Xu wrote:
> On Mon, Aug 05, 2024 at 10:42:06PM +0100, Russell King (Oracle) wrote:
> >
> > We get to the __cbc(aes) entry, and this one seems to trigger the
> > larval_wait thing. With debug in crypto_alg_mod_lookup(), I find
> > this:
> >
> > [ 25.131852] modprobe:613: crypto_alg_mod_lookup: name=cbc(aes) type=0x5 mask=0x218e ok=32769
> > ...
> > [ 87.015070] name=cbc(aes) alg=0xffffff92
> >
> > and 0xffffff92 is an error-pointer for ETIMEDOUT.
>
> Looks like something has gone wrong during the instantiation of
> the fallback cbc algorithm. I'm looking into it.
OK I tracked it down to a recursive module load that hangs because
of this commit:
commit 9b9879fc03275ffe0da328cf5b864d9e694167c8
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Mon May 29 21:39:51 2023 -0400
modules: catch concurrent module loads, treat them as idempotent
So what's happening here is that the first modprobe tries to load
a fallback CBC implementation, in doing so it triggers a load of
the exact same module due to module aliases.
IOW we're loading aes-arm-bs which provides cbc(aes). However, this
needs a fallback of cbc(aes) to operate, which is made out of the
generic cbc module + any implementation of aes, or ecb(aes). The
latter happens to also be provided by aes-arm-cb so that's why it
tries to load the same module again.
Now I presume this used to just fail immediately which is OK because
user-space would then try to load other aliases of ecb(aes). But it
now hangs which causes the whole thing to freeze until a timeout
hits somwhere along the line.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
