Hi David,
On 5/27/22, David Laight <[email protected]> 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