Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753173AbdGSHDA (ORCPT ); Wed, 19 Jul 2017 03:03:00 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:48474 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753103AbdGSHC6 (ORCPT ); Wed, 19 Jul 2017 03:02:58 -0400 Date: Wed, 19 Jul 2017 15:02:17 +0800 From: Herbert Xu To: Megha Dey Cc: Tim Chen , davem@davemloft.net, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code Message-ID: <20170719070217.GA9374@gondor.apana.org.au> References: <1498609575-6217-1-git-send-email-megha.dey@linux.intel.com> <1498609575-6217-6-git-send-email-megha.dey@linux.intel.com> <20170718054142.GA4764@gondor.apana.org.au> <1500427139.32379.0.camel@megha-Z97X-UD7-TH> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1500427139.32379.0.camel@megha-Z97X-UD7-TH> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1612 Lines: 47 On Tue, Jul 18, 2017 at 06:18:59PM -0700, Megha Dey wrote: > > > >> +/* > > >> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk > > >> + * scatter-gather walk. > > >> + */ > > >> +static struct skcipher_alg aes_cbc_mb_alg = { > > >> + .base = { > > >> + .cra_name = "cbc(aes)", > > >> + .cra_driver_name = "cbc-aes-aesni-mb", > > >> + .cra_priority = 500, > > >> + .cra_flags = CRYPTO_ALG_INTERNAL, > > >> + .cra_blocksize = AES_BLOCK_SIZE, > > >> + .cra_ctxsize = CRYPTO_AES_CTX_SIZE, > > >> + .cra_module = THIS_MODULE, > > >> + }, > > >> + .min_keysize = AES_MIN_KEY_SIZE, > > >> + .max_keysize = AES_MAX_KEY_SIZE, > > >> + .ivsize = AES_BLOCK_SIZE, > > >> + .setkey = aes_set_key, > > >> + .encrypt = mb_aes_cbc_encrypt, > > >> + .decrypt = mb_aes_cbc_decrypt > > >> +}; > > > > > > So this claims to be a sync algorithm. Is this really the case? > > yes, the inner algorithm is sync whereas the outer algorithm is async. Are you saying that once mb_aes_cbc_encrypt returns it will never touch the input/output again? This doesn't seem to agree with the actual code: + if (!ret_rctx) { + /* we submitted a job, but none completed */ + /* just notify the caller */ + notify_callback(rctx, cstate, -EINPROGRESS); + return 0; + } Just because an algorithm is internal doesn't mean that it can arbitrarily violate the crypto API requirements. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt