Re: [PATCH crypto v2] crypto: blake2s - remove shash module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

On 5/27/22, David Laight <David.Laight@xxxxxxxxxx> 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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux