Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
In-Reply-To: <ffa404b7427043fda4b9f4a20ea0f068@AcuMS.aculab.com>
References: <YpCGQvpirQWaAiRF@zx2c4.com> <20220527081106.63227-1-Jason@zx2c4.com>
 <ffa404b7427043fda4b9f4a20ea0f068@AcuMS.aculab.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Fri, 27 May 2022 15:20:53 +0200
Message-ID: <CAHmME9osMkustaPdiGmJ02A+5gTPvEy1EJwi5ump7REJXb1-TQ@mail.gmail.com>
Subject: Re: [PATCH crypto v2] crypto: blake2s - remove shash module
To:     David Laight <David.Laight@aculab.com>
Cc:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        gaochao <gaochao49@huawei.com>,
        Eric Biggers <ebiggers@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi David,

On 5/27/22, David Laight <David.Laight@aculab.com> wrote:
> From: Jason A. Donenfeld
>> Sent: 27 May 2022 09:11
>>
>> BLAKE2s has no use as an shash, with no users of it. Just remove all of
>> this unnecessary plumbing. Removing this shash was something we talked
>> about back when we were making BLAKE2s a built-in, but I simply never
>> got around to doing it. So this completes that project.
> ...
>> diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
>> index c71c09621c09..716da32cf4dc 100644
>> --- a/lib/crypto/blake2s.c
>> +++ b/lib/crypto/blake2s.c
>> @@ -16,16 +16,43 @@
>>  #include <linux/init.h>
>>  #include <linux/bug.h>
>>
>> +static inline void blake2s_set_lastblock(struct blake2s_state *state)
>> +{
>> +	state->f[0] = -1;
>> +}
>> +
>>  void blake2s_update(struct blake2s_state *state, const u8 *in, size_t
>> inlen)
>>  {
>> -	__blake2s_update(state, in, inlen, false);
>> +	const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
>> +
>> +	if (unlikely(!inlen))
>> +		return;
>
> Does this happen often enough to optimise for?
> The zero length memcpy() should be fine.
> (though pedants might worry about in == NULL)
>

I don't know and don't care here. This is a straight copy and paste
for the removal. It is not the place for random performance
optimizations.

I have now witnessed you have random performance optimization ideas in
at least 7 threads, usually unrelated to whatever the topic is. As I
keep telling you every time: SEND A PATCH. Those capital letters are
intentional: I care about the same things you do, so please send a
patch so that all that stuff actually happens. Talk is cheap.

Jason