[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170803052733.GA11871@gondor.apana.org.au>
Date: Thu, 3 Aug 2017 13:27:33 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Megha Dey <megha.dey@...ux.intel.com>
Cc: tim.c.chen@...ux.intel.com, davem@...emloft.net,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
megha.dey@...el.com
Subject: Re: [PATCH V7 5/7] crypto: AES CBC multi-buffer glue code
On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote:
>
> +/* notify the caller of progress ; request still stays in queue */
> +
> +static void notify_callback(struct mcryptd_skcipher_request_ctx *rctx,
> + struct mcryptd_alg_cstate *cstate,
> + int err)
> +{
> + struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
> +
> + local_bh_disable();
> + rctx->complete(&req->base, err);
> + local_bh_enable();
> +}
Please explain why you have this crazy construct that does async
operations behind the crypto API's back while pretending to be sync
by always returning zero?
Why is this even needed now that you have switched the underlying
implementation to be async?
> + /* from mcryptd, we need to callback */
> + if (irqs_disabled())
> + rctx->complete(&req->base, err);
> + else {
> + local_bh_disable();
> + rctx->complete(&req->base, err);
> + local_bh_enable();
> + }
I complained about this the first time around and yet this crap is
still there.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists