From: Tim Chen <tim.c.chen@linux.intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
Megha Dey <megha.dey@linux.intel.com>
Cc: davem@davemloft.net, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, megha.dey@intel.com
Subject: Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code
Date: Tue, 18 Jul 2017 17:52:34 -0700 [thread overview]
Message-ID: <da15ba80-a3b1-0d79-47ea-5528c0d12b20@linux.intel.com> (raw)
In-Reply-To: <20170718054142.GA4764@gondor.apana.org.au>
On 07/17/2017 10:41 PM, Herbert Xu wrote:
> On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
>>
>> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
>> + struct mcryptd_alg_cstate *cstate,
>> + int err)
>> +{
>> + struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
>> +
>> + /* remove from work list and invoke completion callback */
>> + spin_lock(&cstate->work_lock);
>> + list_del(&rctx->waiter);
>> + spin_unlock(&cstate->work_lock);
>> +
>> + if (irqs_disabled())
>> + rctx->complete(&req->base, err);
>> + else {
>> + local_bh_disable();
>> + rctx->complete(&req->base, err);
>> + local_bh_enable();
>> + }
>> +}
>
> The fact that you need to do this check means that this design is
> wrong. You should always know what context you are in.
>
I think you are right. The irqs_disabled check is not necessary
as we only call this function in the context of the mcryptd thread.
When I wrote the original mb algorithms I was probably unsure
and put this check in as a precaution in other mb algorithms and
Megha did the same.
>> +/*
>> + * 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?
>
> Cheers,
>
next prev parent reply other threads:[~2017-07-19 0:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 0:26 [PATCH V6 0/7] crypto: AES CBC multibuffer implementation Megha Dey
2017-06-28 0:26 ` [PATCH V6 1/7] crypto: Multi-buffer encryption infrastructure support Megha Dey
2017-06-28 0:26 ` [PATCH V6 2/7] crypto: AES CBC multi-buffer data structures Megha Dey
2017-06-28 0:26 ` [PATCH V6 3/7] crypto: AES CBC multi-buffer scheduler Megha Dey
2017-06-28 0:26 ` [PATCH V6 4/7] crypto: AES CBC by8 encryption Megha Dey
2017-06-28 0:26 ` [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code Megha Dey
2017-07-18 5:41 ` Herbert Xu
2017-07-19 0:52 ` Tim Chen [this message]
2017-07-19 1:18 ` Megha Dey
2017-07-19 7:02 ` Herbert Xu
2017-06-28 0:26 ` [PATCH V6 6/7] crypto: AES vectors for AES CBC multibuffer testing Megha Dey
2017-06-28 0:26 ` [PATCH V6 7/7] crypto: AES CBC multi-buffer tcrypt Megha Dey
2017-07-18 0:18 ` [PATCH V6 0/7] crypto: AES CBC multibuffer implementation Megha Dey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da15ba80-a3b1-0d79-47ea-5528c0d12b20@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=megha.dey@intel.com \
--cc=megha.dey@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome