Date:   Mon, 8 Apr 2019 10:44:02 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     linux-crypto@vger.kernel.org
Subject: Re: [RFC/RFT PATCH 18/18] crypto: run initcalls for generic
 implementations earlier
Message-ID: <20190408174402.GB9145@gmail.com>
References: <20190331200428.26597-19-ebiggers@kernel.org>
 <20190408055322.kke6emtixhhbkppn@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190408055322.kke6emtixhhbkppn@gondor.apana.org.au>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 08, 2019 at 01:53:22PM +0800, Herbert Xu wrote:
> Hi Eric:
> 
> Eric Biggers <ebiggers@kernel.org> wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Use subsys_initcall for registration of all templates and generic
> > algorithm implementations, rather than module_init.
> 
> I think this is fine except that algboss already hooks in at
> subsys_initcall and either it needs to move further up or we
> need to change these ones to occur after subsys_initcall.
> 
> Otherwise the generic algorithms themselves may not get tested
> if algboss isn't loaded first.
> 
> 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

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().

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?

- Eric