public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
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>
Subject: Re: [PATCH] crypto: api - Fix built-in testing dependency failures
Date: Mon, 13 Sep 2021 11:16:03 -0700	[thread overview]
Message-ID: <YT+VYx7OKELJafYz@sol.localdomain> (raw)
In-Reply-To: <20210913071251.GA15235@gondor.apana.org.au>

On Mon, Sep 13, 2021 at 03:12:51PM +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.

Are there any specific examples that you could give?

>  int crypto_register_alg(struct crypto_alg *alg)
>  {
>  	struct crypto_larval *larval;
> +	bool tested;
>  	int err;
>  
>  	alg->cra_flags &= ~CRYPTO_ALG_DEAD;
> @@ -421,12 +402,15 @@ int crypto_register_alg(struct crypto_alg *alg)
>  
>  	down_write(&crypto_alg_sem);
>  	larval = __crypto_register_alg(alg);
> +	tested = static_key_enabled(&crypto_boot_test_finished);
> +	larval->tested = tested;

'tested' is set before the algorithm has actually been tested, and it sounds
like the same as CRYPTO_ALG_TESTED which already exists.  Maybe it should be
called something else, like 'test_started'?

> +static void __init crypto_start_tests(void)
> +{
> +	for (;;) {
> +		struct crypto_larval *larval = NULL;
> +		struct crypto_alg *q;
> +
> +		down_write(&crypto_alg_sem);
> +
> +		list_for_each_entry(q, &crypto_alg_list, cra_list) {
> +			struct crypto_larval *l;
> +
> +			if (!crypto_is_larval(q))
> +				continue;
> +
> +			l = (void *)q;
> +
> +			if (!crypto_is_test_larval(l))
> +				continue;
> +
> +			if (l->tested)
> +				continue;
> +
> +			l->tested = true;
> +			larval = l;
> +			break;
> +		}
> +
> +		up_write(&crypto_alg_sem);
> +
> +		if (!larval)
> +			break;
> +
> +		crypto_wait_for_test(larval);
> +	}

Is there a way to continue iterating from the previous algorithm, so that this
doesn't take quadratic time?

> +
> +	static_branch_enable(&crypto_boot_test_finished);
> +}
> +
>  static int __init crypto_algapi_init(void)
>  {
>  	crypto_init_proc();
> +	crypto_start_tests();

A comment explaining why the tests aren't run until late_initcall would be
helpful.  People shouldn't have to dig through commit messages to understand the
code.

Also, did you check whether there is anything that relies on the crypto API
being available before or during late_initcall?  That wouldn't work with this
new approach, right?

- Eric

  reply	other threads:[~2021-09-13 18:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13  7:12 [PATCH] crypto: api - Fix built-in testing dependency failures Herbert Xu
2021-09-13 18:16 ` Eric Biggers [this message]
2021-09-14  3:28   ` Herbert Xu
2021-09-17  0:26 ` [v2 PATCH] " Herbert Xu
2021-09-28 18:32   ` Nathan Chancellor
2021-10-01  5:50     ` Herbert Xu
2021-10-01 10:58       ` Naresh Kamboju
2021-10-01 18:01       ` Nathan Chancellor
2021-10-03  0:28         ` Herbert Xu
2021-10-06  2:33           ` Nathan Chancellor
2021-10-19 13:28             ` [PATCH] crypto: api - Do not create test larvals if manager is disabled Herbert Xu
2021-11-02 15:41               ` Geert Uytterhoeven
2021-11-04  7:28                 ` Damien Le Moal
2021-11-04  7:58                   ` Geert Uytterhoeven
2021-11-04  8:05                     ` Damien Le Moal
2021-11-04 12:16                     ` Herbert Xu
2021-11-04 13:11                       ` Geert Uytterhoeven
2021-11-04 13:30                         ` Herbert Xu
2021-11-04 15:18                           ` Ido Schimmel
2021-11-05  7:26                             ` crypto: api - Fix boot-up crash when crypto " Herbert Xu
2021-11-05 14:33                               ` Ido Schimmel
2021-11-05 18:00                               ` Geert Uytterhoeven
2021-10-26 16:33   ` [v2 PATCH] crypto: api - Fix built-in testing dependency failures Guenter Roeck
2021-10-27  2:59     ` Herbert Xu
2021-10-27  3:48       ` Guenter Roeck
2021-11-06  3:47     ` Herbert Xu
2021-11-06 14:55       ` Guenter Roeck
2021-12-22 10:22         ` Uwe Kleine-König
2021-12-22 10:37           ` Uwe Kleine-König
2021-12-29  2:05           ` Herbert Xu
2021-12-29 11:05             ` Uwe Kleine-König
2022-03-16  1:10               ` Herbert Xu
2022-03-16 16:37                 ` Uwe Kleine-König
2022-03-16 21:44                   ` Uwe Kleine-König
2022-03-16 22:38                     ` Herbert Xu
2022-03-16 22:55                   ` [PATCH] crypto: arm/aes-neonbs-cbc - Select generic cbc and aes Herbert Xu
2022-03-17  7:11                     ` Uwe Kleine-König
2022-03-17  9:16                     ` Philipp Zabel
2022-03-17 22:15                       ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YT+VYx7OKELJafYz@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=ssorce@redhat.com \
    --cc=vdronov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox