* crypto: algboss - Avoid spurious modprobe on LOADED
@ 2020-04-07 3:00 Herbert Xu
2020-04-07 4:58 ` Eric Biggers
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2020-04-07 3:00 UTC (permalink / raw)
To: Linux Crypto Mailing List
As it stands when any algorithm finishes testing a notification
is generated which triggers an unnecessary modprobe because algboss
returns NOTIFY_DONE instead of NOTIFY_OK (this denotes an event
that is not handled properly).
This patch changes the return value in algboss so that we don't
do an unnecessary modprobe.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/algboss.c b/crypto/algboss.c
index 527b44d0af21..01feb8234053 100644
--- a/crypto/algboss.c
+++ b/crypto/algboss.c
@@ -275,7 +275,7 @@ static int cryptomgr_notify(struct notifier_block *this, unsigned long msg,
case CRYPTO_MSG_ALG_REGISTER:
return cryptomgr_schedule_test(data);
case CRYPTO_MSG_ALG_LOADED:
- break;
+ return NOTIFY_OK;
}
return NOTIFY_DONE;
--
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: crypto: algboss - Avoid spurious modprobe on LOADED
2020-04-07 3:00 crypto: algboss - Avoid spurious modprobe on LOADED Herbert Xu
@ 2020-04-07 4:58 ` Eric Biggers
2020-04-07 5:17 ` Herbert Xu
0 siblings, 1 reply; 6+ messages in thread
From: Eric Biggers @ 2020-04-07 4:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linux Crypto Mailing List
On Tue, Apr 07, 2020 at 01:00:03PM +1000, Herbert Xu wrote:
> As it stands when any algorithm finishes testing a notification
> is generated which triggers an unnecessary modprobe because algboss
> returns NOTIFY_DONE instead of NOTIFY_OK (this denotes an event
> that is not handled properly).
>
> This patch changes the return value in algboss so that we don't
> do an unnecessary modprobe.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Needs a Fixes tag?
Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms")
Cc: <stable@vger.kernel.org> # v4.20+
>
> diff --git a/crypto/algboss.c b/crypto/algboss.c
> index 527b44d0af21..01feb8234053 100644
> --- a/crypto/algboss.c
> +++ b/crypto/algboss.c
> @@ -275,7 +275,7 @@ static int cryptomgr_notify(struct notifier_block *this, unsigned long msg,
> case CRYPTO_MSG_ALG_REGISTER:
> return cryptomgr_schedule_test(data);
> case CRYPTO_MSG_ALG_LOADED:
> - break;
> + return NOTIFY_OK;
> }
>
> return NOTIFY_DONE;
It's hard to remember the difference between NOTIFY_OK and NOTIFY_DONE. Isn't
it wrong to call request_module() in the first place for a message that
"cryptomgr" doesn't care about? Wouldn't the following make more sense?:
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 69605e21af92..849254d7e627 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -403,7 +403,7 @@ static void crypto_wait_for_test(struct crypto_larval *larval)
err = wait_for_completion_killable(&larval->completion);
WARN_ON(err);
if (!err)
- crypto_probing_notify(CRYPTO_MSG_ALG_LOADED, larval);
+ crypto_notify(CRYPTO_MSG_ALG_LOADED, larval);
out:
crypto_larval_kill(&larval->alg);
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: crypto: algboss - Avoid spurious modprobe on LOADED
2020-04-07 4:58 ` Eric Biggers
@ 2020-04-07 5:17 ` Herbert Xu
2020-04-07 6:02 ` [PATCH v2] crypto: algapi " Eric Biggers
0 siblings, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2020-04-07 5:17 UTC (permalink / raw)
To: Eric Biggers; +Cc: Linux Crypto Mailing List
On Mon, Apr 06, 2020 at 09:58:35PM -0700, Eric Biggers wrote:
>
> Needs a Fixes tag?
>
> Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms")
> Cc: <stable@vger.kernel.org> # v4.20+
Ah thanks, I had thought this was an ancient bug and therefore
the fixes wouldn't have been that useful. The fact that it is
a recent introduction means that we definitely should have the
tags.
> > diff --git a/crypto/algboss.c b/crypto/algboss.c
> > index 527b44d0af21..01feb8234053 100644
> > --- a/crypto/algboss.c
> > +++ b/crypto/algboss.c
> > @@ -275,7 +275,7 @@ static int cryptomgr_notify(struct notifier_block *this, unsigned long msg,
> > case CRYPTO_MSG_ALG_REGISTER:
> > return cryptomgr_schedule_test(data);
> > case CRYPTO_MSG_ALG_LOADED:
> > - break;
> > + return NOTIFY_OK;
> > }
> >
> > return NOTIFY_DONE;
>
> It's hard to remember the difference between NOTIFY_OK and NOTIFY_DONE. Isn't
> it wrong to call request_module() in the first place for a message that
> "cryptomgr" doesn't care about? Wouldn't the following make more sense?:
Good point. Yes we can and should do that here. Can you post
a patch for this please?
Cheers,
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] crypto: algapi - Avoid spurious modprobe on LOADED
2020-04-07 5:17 ` Herbert Xu
@ 2020-04-07 6:02 ` Eric Biggers
2020-04-07 17:26 ` Martin K. Petersen
2020-04-16 6:52 ` Herbert Xu
0 siblings, 2 replies; 6+ messages in thread
From: Eric Biggers @ 2020-04-07 6:02 UTC (permalink / raw)
To: linux-crypto; +Cc: stable, Martin K . Petersen
From: Eric Biggers <ebiggers@google.com>
Currently after any algorithm is registered and tested, there's an
unnecessary request_module("cryptomgr") even if it's already loaded.
Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is
"crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once.
This occurs because CRYPTO_MSG_ALG_LOADED is sent using
crypto_probing_notify(), which tries to load "cryptomgr" if the
notification is not handled (NOTIFY_DONE). This doesn't make sense
because "cryptomgr" doesn't handle this notification.
Fix this by using crypto_notify() instead of crypto_probing_notify().
Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms")
Cc: <stable@vger.kernel.org> # v4.20+
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/algapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 69605e21af92..849254d7e627 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -403,7 +403,7 @@ static void crypto_wait_for_test(struct crypto_larval *larval)
err = wait_for_completion_killable(&larval->completion);
WARN_ON(err);
if (!err)
- crypto_probing_notify(CRYPTO_MSG_ALG_LOADED, larval);
+ crypto_notify(CRYPTO_MSG_ALG_LOADED, larval);
out:
crypto_larval_kill(&larval->alg);
--
2.26.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] crypto: algapi - Avoid spurious modprobe on LOADED
2020-04-07 6:02 ` [PATCH v2] crypto: algapi " Eric Biggers
@ 2020-04-07 17:26 ` Martin K. Petersen
2020-04-16 6:52 ` Herbert Xu
1 sibling, 0 replies; 6+ messages in thread
From: Martin K. Petersen @ 2020-04-07 17:26 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, stable, Martin K . Petersen
Eric,
> Currently after any algorithm is registered and tested, there's an
> unnecessary request_module("cryptomgr") even if it's already loaded.
> Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm
> is "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than
> once.
>
> This occurs because CRYPTO_MSG_ALG_LOADED is sent using
> crypto_probing_notify(), which tries to load "cryptomgr" if the
> notification is not handled (NOTIFY_DONE). This doesn't make sense
> because "cryptomgr" doesn't handle this notification.
>
> Fix this by using crypto_notify() instead of crypto_probing_notify().
Looks good to me.
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] crypto: algapi - Avoid spurious modprobe on LOADED
2020-04-07 6:02 ` [PATCH v2] crypto: algapi " Eric Biggers
2020-04-07 17:26 ` Martin K. Petersen
@ 2020-04-16 6:52 ` Herbert Xu
1 sibling, 0 replies; 6+ messages in thread
From: Herbert Xu @ 2020-04-16 6:52 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, stable, Martin K . Petersen
On Mon, Apr 06, 2020 at 11:02:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Currently after any algorithm is registered and tested, there's an
> unnecessary request_module("cryptomgr") even if it's already loaded.
> Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is
> "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once.
>
> This occurs because CRYPTO_MSG_ALG_LOADED is sent using
> crypto_probing_notify(), which tries to load "cryptomgr" if the
> notification is not handled (NOTIFY_DONE). This doesn't make sense
> because "cryptomgr" doesn't handle this notification.
>
> Fix this by using crypto_notify() instead of crypto_probing_notify().
>
> Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms")
> Cc: <stable@vger.kernel.org> # v4.20+
> Cc: Martin K. Petersen <martin.petersen@oracle.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
> ---
> crypto/algapi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-16 6:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-07 3:00 crypto: algboss - Avoid spurious modprobe on LOADED Herbert Xu
2020-04-07 4:58 ` Eric Biggers
2020-04-07 5:17 ` Herbert Xu
2020-04-07 6:02 ` [PATCH v2] crypto: algapi " Eric Biggers
2020-04-07 17:26 ` Martin K. Petersen
2020-04-16 6:52 ` Herbert Xu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).