From: Herbert Xu <herbert@gondor.apana.org.au>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"David S.Miller" <davem@davemloft.net>,
Stephan Mueller <smueller@chronox.de>,
Chandramouli Narayanan <mouli_7982@yahoo.com>,
Vinodh Gopal <vinodh.gopal@intel.com>,
James Guilford <james.guilford@intel.com>,
Wajdi Feghali <wajdi.k.feghali@intel.com>,
Jussi Kivilinna <jussi.kivilinna@iki.fi>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support
Date: Thu, 19 Nov 2015 08:12:01 +0800 [thread overview]
Message-ID: <20151119001201.GA24293@gondor.apana.org.au> (raw)
In-Reply-To: <1447862336.4933.36.camel@schen9-desk2.jf.intel.com>
On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote:
>
> IPSec will invoke this multi-buffer encrypt with async request.
> The work is done in crypto daemon, so it wouldn't be in atomic
> context. But anyway, I'm okay with switching to ablkcipher walk,
> as long as it doesn't incur too much more overhead than blkcipher
> walk.
What if some other user called the blkcipher interface in an atomic
context? You can't guarantee that your algorithm is only picked up
through the ablkcipher interface, unless of course you do something
like __driver-ctr-aes-aesni.
Hmm I was just looking at the sha_mb code and something doesn't
look right. For instance, can sha1_mb_update ever return
-EINPROGRESS? This would be wrong as it's registered as an shash
algorithm.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2015-11-19 0:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1446158797.git.tim.c.chen@linux.intel.com>
2015-10-29 22:20 ` [PATCH v2 0/5] crypto: x86 AES-CBC encryption with multibuffer Tim Chen
2015-10-29 22:21 ` [PATCH v2 1/5] crypto: Multi-buffer encryptioin infrastructure support Tim Chen
2015-11-17 13:06 ` Herbert Xu
2015-11-17 22:59 ` Tim Chen
2015-11-18 0:07 ` Herbert Xu
2015-11-18 0:30 ` Tim Chen
2015-11-18 5:06 ` Herbert Xu
2015-11-18 15:58 ` Tim Chen
2015-11-19 0:12 ` Herbert Xu [this message]
2015-11-19 2:39 ` Tim Chen
2015-11-19 9:39 ` Herbert Xu
2015-10-29 22:21 ` [PATCH v2 2/5] crypto: AES CBC multi-buffer data structures Tim Chen
2015-10-29 22:21 ` [PATCH v2 3/5] crypto: AES CBC multi-buffer scheduler Tim Chen
2015-10-29 22:21 ` [PATCH v2 4/5] crypto: AES CBC by8 encryption Tim Chen
2015-10-29 22:21 ` [PATCH v2 5/5] crypto: AES CBC multi-buffer glue code Tim Chen
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=20151119001201.GA24293@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=james.guilford@intel.com \
--cc=jussi.kivilinna@iki.fi \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mouli_7982@yahoo.com \
--cc=smueller@chronox.de \
--cc=tim.c.chen@linux.intel.com \
--cc=vinodh.gopal@intel.com \
--cc=wajdi.k.feghali@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