On Mon, Apr 08, 2019 at 10:44:02AM -0700, Eric Biggers wrote:
>
> My patch also moved cryptomgr earlier in the Makefile, so it's linked first. Do
> you think that's too fragile? Otherwise, I'll probably change cryptomgr_init()
> to arch_initcall().
I don't think we should rely on link-time ordering to fulfil
this as it will just fail silently when it breaks.
> BTW, I found another problem caused by allocating the generic implementation
> during the self-tests, which is that the generic implementation will fulfill any
> outstanding allocation requests before the other implementation has finished
> testing. E.g. on x86_64, the first call to
>
> crypto_alloc_skcipher("adiantum(xchacha12,aes)", 0, 0)
>
> will get "adiantum(xchacha12-generic,aes-generic,nhpoly1305-generic)" rather
> than "adiantum(xchacha12-simd,aes-aesni,nhpoly1305-avx2)" as expected. Do you
> have any suggestion on the best way to fix this?
Well this is to be expected. Normally we don't start the allocation
until all probing is done. That is, all modules should have been
loaded before (or rather during) the first allocation call. If it
occurs during the first allocation call then a larval algorithm will
hold any subsequent allocations until the testing is done.
So the question is who is doing the allocation prior the registration
of the accelerated algorithms? Is it the fuzzing test?
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
