From: Ard Biesheuvel <ardb@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>, Megha Dey <megha.dey@intel.com>,
Eric Biggers <ebiggers@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: [PATCH v2 3/5] crypto: x86/gcm-aes-ni - clean up mapping of associated data
Date: Mon, 4 Jan 2021 16:55:48 +0100 [thread overview]
Message-ID: <20210104155550.6359-4-ardb@kernel.org> (raw)
In-Reply-To: <20210104155550.6359-1-ardb@kernel.org>
The gcm(aes-ni) driver is only built for x86_64, which does not make
use of highmem. So testing for PageHighMem is pointless and can be
omitted.
While at it, replace GFP_ATOMIC with the appropriate runtime decided
value based on the context.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/x86/crypto/aesni-intel_glue.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 0f124d72e6b4..26b012065701 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -667,14 +667,15 @@ static int gcmaes_crypt_by_sg(bool enc, struct aead_request *req,
gcm_tfm = &aesni_gcm_tfm_sse;
/* Linearize assoc, if not already linear */
- if (req->src->length >= assoclen && req->src->length &&
- (!PageHighMem(sg_page(req->src)) ||
- req->src->offset + req->src->length <= PAGE_SIZE)) {
+ if (req->src->length >= assoclen && req->src->length) {
scatterwalk_start(&assoc_sg_walk, req->src);
assoc = scatterwalk_map(&assoc_sg_walk);
} else {
+ gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP)
+ ? GFP_KERNEL : GFP_ATOMIC;
+
/* assoc can be any length, so must be on heap */
- assocmem = kmalloc(assoclen, GFP_ATOMIC);
+ assocmem = kmalloc(assoclen, flags);
if (unlikely(!assocmem))
return -ENOMEM;
assoc = assocmem;
--
2.17.1
next prev parent reply other threads:[~2021-01-04 15:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 15:55 [PATCH v2 0/5] crypto: gcm-aes-ni cleanups Ard Biesheuvel
2021-01-04 15:55 ` [PATCH v2 1/5] crypto: x86/gcm-aes-ni - prevent misaligned buffers on the stack Ard Biesheuvel
2021-01-04 15:55 ` [PATCH v2 2/5] crypto: x86/gcm-aes-ni - drop unused asm prototypes Ard Biesheuvel
2021-01-04 15:55 ` Ard Biesheuvel [this message]
2021-01-04 15:55 ` [PATCH v2 4/5] crypto: x86/gcm-aes-ni - refactor scatterlist processing Ard Biesheuvel
2021-01-04 15:55 ` [PATCH v2 5/5] crypto: x86/gcm-aes-ni - replace function pointers with static branches Ard Biesheuvel
2021-01-14 6:46 ` [PATCH v2 0/5] crypto: gcm-aes-ni cleanups 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=20210104155550.6359-4-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=ebiggers@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=megha.dey@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 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.