On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
On 26/04/17 09:56 PM, Herbert Xu wrote:
On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
Very straightforward conversion to the new function in the caam driver and shash library.
Signed-off-by: Logan Gunthorpe logang@deltatee.com Cc: Herbert Xu herbert@gondor.apana.org.au Cc: "David S. Miller" davem@davemloft.net
crypto/shash.c | 9 ++++++--- drivers/crypto/caam/caamalg.c | 8 +++----- 2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/crypto/shash.c b/crypto/shash.c index 5e31c8d..5914881 100644 --- a/crypto/shash.c +++ b/crypto/shash.c @@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc) if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) { void *data;
data = kmap_atomic(sg_page(sg));err = crypto_shash_digest(desc, data + offset, nbytes,
data = sg_map(sg, 0, SG_KMAP_ATOMIC);if (IS_ERR(data))return PTR_ERR(data);err = crypto_shash_digest(desc, data, nbytes, req->result);
kunmap_atomic(data);
sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);Nack. This is an optimisation for the special case of a single SG list entry. In fact in the common case the kmap_atomic should disappear altogether in the no-highmem case. So replacing it with sg_map is not acceptable.
What you seem to have missed is that sg_map is just a thin wrapper around kmap_atomic. Perhaps with a future check for a mappable page. This change should have zero impact on performance.
You are right. Indeed the existing code looks buggy as they don't take sg->offset into account when doing the kmap. Could you send me some patches that fix these problems first so that they can be easily backported?
Thanks,