From: Ard Biesheuvel Subject: Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash Date: Mon, 26 Dec 2016 17:51:14 +0000 Message-ID: References: <942b91f25a63b22ec4946378a1fffe78d655cf18.1482545792.git.luto@kernel.org> <20161226075757.GA8916@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Andy Lutomirski , Andy Lutomirski , Daniel Borkmann , Netdev , LKML , Linux Crypto Mailing List , "Jason A. Donenfeld" , Hannes Frederic Sowa , Alexei Starovoitov , Eric Dumazet , Eric Biggers , Tom Herbert , "David S. Miller" To: Herbert Xu Return-path: Received: from mail-io0-f181.google.com ([209.85.223.181]:34562 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753418AbcLZRwN (ORCPT ); Mon, 26 Dec 2016 12:52:13 -0500 Received: by mail-io0-f181.google.com with SMTP id p42so300104322ioo.1 for ; Mon, 26 Dec 2016 09:51:15 -0800 (PST) In-Reply-To: <20161226075757.GA8916@gondor.apana.org.au> Sender: linux-crypto-owner@vger.kernel.org List-ID: On 26 December 2016 at 07:57, Herbert Xu wrote: > On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote: >> >> I actually do use incremental hashing later on. BPF currently >> vmallocs() a big temporary buffer just so it can fill it and hash it. >> I change it to hash as it goes. > > How much data is this supposed to hash on average? If it's a large > amount then perhaps using the existing crypto API would be a better > option than adding this. > This is a good point actually: you didn't explain *why* BPF shouldn't depend on the crypto API.