From: Eric Biggers <ebiggers@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 1/16] crypto: skcipher - Add skcipher walk interface
Date: Sun, 13 Nov 2016 17:35:48 -0800 [thread overview]
Message-ID: <20161114013548.GA4778@google.com> (raw)
In-Reply-To: <E1c5tE4-00028Y-BC@gondolin.me.apana.org.au>
Hi Herbert,
On Sun, Nov 13, 2016 at 07:45:32PM +0800, Herbert Xu wrote:
> +int skcipher_walk_done(struct skcipher_walk *walk, int err)
> +{
> + unsigned int nbytes = 0;
> + unsigned int n = 0;
> +
> + if (likely(err >= 0)) {
> + n = walk->nbytes - err;
> + nbytes = walk->total - n;
> + }
> +
> + if (likely(!(walk->flags & (SKCIPHER_WALK_PHYS |
> + SKCIPHER_WALK_SLOW |
> + SKCIPHER_WALK_COPY |
> + SKCIPHER_WALK_DIFF)))) {
> +unmap_src:
> + skcipher_unmap_src(walk);
Isn't it wrong to unmap the buffers when err < 0? They won't have been mapped
yet, e.g. if the 'skcipher_walk_done(walk, -EINVAL)' case is hit.
> + /* Short-circuit for the common/fast path. */
> + if (!(((unsigned long)walk->iv ^ (unsigned long)walk->oiv) |
> + ((unsigned long)walk->buffer ^ (unsigned long)walk->page) |
> + (unsigned long)walk->page))
> + goto out;
This is really saying that the IV wasn't copied and that walk->buffer and
walk->page are both NULL. But if walk->buffer is NULL then the IV wasn't
copied. So this can be simplified to:
if (!((unsigned long)walk->buffer | (unsigned long)walk->page))
goto out;
> +int skcipher_walk_next(struct skcipher_walk *walk)
> +{
Shouldn't this be static? There's even a static declaration earlier in the
file.
> +static int skcipher_next_slow(struct skcipher_walk *walk)
> +{
> + bool phys = walk->flags & SKCIPHER_WALK_PHYS;
> + unsigned alignmask = walk->alignmask;
> + unsigned bsize = walk->chunksize;
...
> + walk->nbytes = bsize;
skcipher_next_slow() is always setting up 'chunksize' bytes to be processed.
Isn't this wrong in the 'blocksize < chunksize' case because fewer than
'chunksize' bytes may need to be processed?
> +static inline void *skcipher_map(struct scatter_walk *walk)
> +{
> + struct page *page = scatterwalk_page(walk);
> +
> + return (PageHighMem(page) ? kmap_atomic(page) : page_address(page)) +
> + offset_in_page(walk->offset);
> +}
Is the PageHighMem() optimization really worthwhile? It will skip kmap_atomic()
and hence preempt_disable() for non-highmem pages, so it may make it harder to
find bugs where users are sleeping when they shouldn't be. It also seems
inconsistent that skcipher_map() will do this optimization but scatterwalk_map()
won't.
> + if (!walk->page) {
> + gfp_t gfp = skcipher_walk_gfp(walk);
> +
> + walk->page = (void *)__get_free_page(gfp);
> + if (!walk->page)
> + goto slow_path;
> + }
> +
> + walk->nbytes = min_t(unsigned, n,
> + PAGE_SIZE - offset_in_page(walk->page));
walk->page will be page-aligned, so there's no need for offset_in_page(). Also,
'n' has already been clamped to at most one page. So AFAICS this can simply be
'walk->nbytes = n;'.
> +int skcipher_walk_done(struct skcipher_walk *walk, int err);
...
> +void skcipher_walk_complete(struct skcipher_walk *walk, int err);
The naming is confusing: "done" vs. "complete". They can easily be mixed up.
Would it make more sense to have something with "async" in the name for the
second one, like skcipher_walk_async_done()?
Eric
next prev parent reply other threads:[~2016-11-14 1:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-13 11:43 [v2 PATCH 0/16] crypto: skcipher - skcipher algorithm conversion part 3 Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 1/16] crypto: skcipher - Add skcipher walk interface Herbert Xu
2016-11-14 1:35 ` Eric Biggers [this message]
2016-11-15 13:58 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 2/16] crypto: aes-ce-ccm - Use " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 3/16] crypto: lrw - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 4/16] crypto: xts " Herbert Xu
2016-11-14 2:10 ` Eric Biggers
2016-11-15 14:41 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 5/16] crypto: api - Do not clear type bits in crypto_larval_lookup Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 6/16] crypto: cryptd - Add support for skcipher Herbert Xu
2016-11-14 1:45 ` Eric Biggers
2016-11-13 11:45 ` [v2 PATCH 7/16] crypto: simd - Add simd skcipher helper Herbert Xu
2016-11-14 2:27 ` Eric Biggers
2016-11-15 14:55 ` Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 8/16] crypto: pcbc - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 9/16] crypto: glue_helper - Add skcipher xts helpers Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 10/16] crypto: testmgr - Do not test internal algorithms Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 11/16] crypto: aesni - Convert to skcipher Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 12/16] crypto: arm64/aes " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 13/16] crypto: aes-ce " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 14/16] crypto: cbc " Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 15/16] crypto: cbc - Export CBC implementation Herbert Xu
2016-11-13 11:45 ` [v2 PATCH 16/16] crypto: aesbs - Convert to skcipher Herbert Xu
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=20161114013548.GA4778@google.com \
--to=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.