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;
Sender: Guenter Roeck <groeck7@gmail.com>
Subject: Re: [v2 PATCH] crypto: api - Fix built-in testing dependency failures
To:     Herbert Xu <herbert@gondor.apana.org.au>
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>
References: <20210913071251.GA15235@gondor.apana.org.au>
 <20210917002619.GA6407@gondor.apana.org.au>
 <20211026163319.GA2785420@roeck-us.net>
 <20211106034725.GA18680@gondor.apana.org.au>
From:   Guenter Roeck <linux@roeck-us.net>
Message-ID: <729fc135-8e55-fd4f-707a-60b9a222ab97@roeck-us.net>
Date:   Sat, 6 Nov 2021 07:55:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <20211106034725.GA18680@gondor.apana.org.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/5/21 8:47 PM, Herbert Xu wrote:
> 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?
> 

No, I don't see that problem anymore, neither in mainline with your
patch applied nor in the latest -next with your patch applied.

Guenter