Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757415AbeAIUvN (ORCPT + 1 other); Tue, 9 Jan 2018 15:51:13 -0500 Received: from mga05.intel.com ([192.55.52.43]:19242 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756698AbeAIUvL (ORCPT ); Tue, 9 Jan 2018 15:51:11 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,336,1511856000"; d="scan'208";a="193652085" Message-ID: <1515532044.2526.4.camel@megha-Z97X-UD7-TH> Subject: Re: [PATCH V7 5/7] crypto: AES CBC multi-buffer glue code From: Megha Dey To: Herbert Xu Cc: tim.c.chen@linux.intel.com, davem@davemloft.net, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 09 Jan 2018 13:07:24 -0800 In-Reply-To: <20170803052733.GA11871@gondor.apana.org.au> References: <1501035000-6283-1-git-send-email-megha.dey@linux.intel.com> <1501035000-6283-6-git-send-email-megha.dey@linux.intel.com> <20170803052733.GA11871@gondor.apana.org.au> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, 2017-08-03 at 13:27 +0800, Herbert Xu wrote: > 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? Hi Herbert, In the next version, I have removed this construct. After giving it some thought, I realise this is actually incorrect. Hopefully now, both the outer and inner algorithm are 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. Sorry about that, will get rid of the context check in the next version. > > Cheers,