Re: [PATCH] crypto : async implementation for sha1-mb
On Tue, Jun 21, 2016 at 06:21:46PM -0700, Megha Dey wrote: > From: Megha Dey > > Herbert wants the sha1-mb algorithm to have an async implementation: > https://lkml.org/lkml/2016/4/5/286. > Currently, sha1-mb uses an async interface for the outer algorithm > and a sync interface for the inner algorithm. This patch introduces > a async interface for even the inner algorithm. > > Signed-off-by: Megha Dey > Signed-off-by: Tim Chen Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto : async implementation for sha1-mb
On Mon, Jun 20, 2016 at 01:25:46PM -0700, Megha Dey wrote:
>
> - desc->tfm = child;
> - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; /* check this again */
> + ahash_request_set_tfm(desc, child);
> + ahash_request_set_callback(desc, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
The callback function needs to be set, or this will crash when
it returns -EINPROGRESS.
> if (err) {
> req->base.complete = rctx->complete;
This is not calling the completion function conditinoally, rather
it is trying to restore the original completion function when we
are done.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto : async implementation for sha1-mb
On Fri, Jun 17, 2016 at 12:28:30PM -0700, Megha Dey wrote:
>
> -static void sha1_mb_async_exit_tfm(struct crypto_tfm *tfm)
> -{
> - struct sha1_mb_ctx *ctx = crypto_tfm_ctx(tfm);
> + ahash_request_set_tfm(areq, child);
> + ahash_request_set_callback(areq, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
You need to fix them all, not just the one that I picked out.
> @@ -874,11 +893,13 @@ static struct ahash_alg sha1_mb_async_alg = {
> .cra_name = "sha1",
> .cra_driver_name= "sha1_mb",
> .cra_priority = 200,
> - .cra_flags = CRYPTO_ALG_TYPE_AHASH |
> CRYPTO_ALG_ASYNC,
> + .cra_flags = CRYPTO_ALG_TYPE_AHASH |
> + CRYPTO_ALG_ASYNC,
Please don't include unrelated changes such as white-space fixes
like this.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto : async implementation for sha1-mb
On Mon, Jun 13, 2016 at 07:10:26PM +, Dey, Megha wrote: > > > In the current implementation, the inner algorithm is called directly, and > > we use the outer algorithm's callback. We do not use the callback in inner > > algorithm. We are actually calling the child functions directly and the > > child is using the parent's call back function. Probably I can add a > > comment before the set callback function.. will this be ok? No this is a hack and you should not do that. You can of course set the inner request's callback to that of the outer request. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] crypto : async implementation for sha1-mb
-Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Monday, June 13, 2016 1:22 AM To: Dey, Megha Cc: tim.c.c...@linux.intel.com; da...@davemloft.net; linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org; Yu, Fenghua ; Megha Dey Subject: Re: [PATCH] crypto : async implementation for sha1-mb On Tue, Jun 07, 2016 at 11:14:42AM -0700, Megha Dey wrote: > > - desc->tfm = child; > - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; > + ahash_request_set_tfm(desc, child); > + ahash_request_set_callback(desc, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, > +NULL); Why are the callbacks set to NULL/NULL? The child is async so you should have a valid callback function here. Instead of continuing to do the broken callback handling outside of the API (i.e., rctx->complete) please use the API mechanism that is provided for this purpose. > In the current implementation, the inner algorithm is called directly, and we > use the outer algorithm's callback. We do not use the callback in inner > algorithm. We are actually calling the child functions directly and the child > is using the parent's call back function. Probably I can add a comment before > the set callback function.. will this be ok? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto : async implementation for sha1-mb
On Tue, Jun 07, 2016 at 11:14:42AM -0700, Megha Dey wrote: > > - desc->tfm = child; > - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; > + ahash_request_set_tfm(desc, child); > + ahash_request_set_callback(desc, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL); Why are the callbacks set to NULL/NULL? The child is async so you should have a valid callback function here. Instead of continuing to do the broken callback handling outside of the API (i.e., rctx->complete) please use the API mechanism that is provided for this purpose. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
