Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 6 Nov 2021 11:47:25 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Guenter Roeck <linux@roeck-us.net>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Vladis Dronov <vdronov@redhat.com>,
        Simo Sorce <ssorce@redhat.com>,
        Eric Biggers <ebiggers@kernel.org>
Subject: Re: [v2 PATCH] crypto: api - Fix built-in testing dependency failures
Message-ID: <20211106034725.GA18680@gondor.apana.org.au>
References: <20210913071251.GA15235@gondor.apana.org.au>
 <20210917002619.GA6407@gondor.apana.org.au>
 <20211026163319.GA2785420@roeck-us.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211026163319.GA2785420@roeck-us.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, Oct 26, 2021 at 09:33:19AM -0700, Guenter Roeck wrote:
> Hi,
> 
> On Fri, Sep 17, 2021 at 08:26:19AM +0800, Herbert Xu wrote:
> > When complex algorithms that depend on other algorithms are built
> > into the kernel, the order of registration must be done such that
> > the underlying algorithms are ready before the ones on top are
> > registered.  As otherwise they would fail during the self-test
> > which is required during registration.
> > 
> > In the past we have used subsystem initialisation ordering to
> > guarantee this.  The number of such precedence levels are limited
> > and they may cause ripple effects in other subsystems.
> > 
> > This patch solves this problem by delaying all self-tests during
> > boot-up for built-in algorithms.  They will be tested either when
> > something else in the kernel requests for them, or when we have
> > finished registering all built-in algorithms, whichever comes
> > earlier.
> > 
> > Reported-by: Vladis Dronov <vdronov@redhat.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > 
> 
> I can not explain it, but this patch causes a crash with one of my boot
> tests (riscv32 with riscv32 virt machine and e1000 network adapter):
> 
> [    9.948557] e1000 0000:00:01.0: enabling device (0000 -> 0003)

Does this still occur with the latest patch I sent yesterday?

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