On Wed, Apr 30, 2025 at 07:26:17PM -0700, Eric Biggers wrote:
>
> Interesting approach -- pushing out misguided optimizations without data, then
> demanding data for them to be reverted. It's obviously worse for
> len % 64 < 56 for the reason I gave, so this is a waste of time IMO. But
> since
>
On Thu, May 01, 2025 at 09:21:15AM +0800, Herbert Xu wrote:
> On Wed, Apr 30, 2025 at 10:45:43AM -0700, Eric Biggers wrote:
> >
> > As for your sha256_finup "optimization", it's an interesting idea, but
> > unfortunately it slightly slows down the common case which is count % 64 <
> > 56,
> > due
On Wed, Apr 30, 2025 at 10:45:43AM -0700, Eric Biggers wrote:
>
> As for your sha256_finup "optimization", it's an interesting idea, but
> unfortunately it slightly slows down the common case which is count % 64 < 56,
> due to the unnecessary copy to the stack and the following zeroization. In
>
[Added back Cc's that were dropped]
On Wed, Apr 30, 2025 at 02:06:15PM +0800, Herbert Xu wrote:
> This is based on
>
> https://patchwork.kernel.org/project/linux-crypto/list/?series=957785
I'm assuming that you mean that with your diff
https://lore.kernel.org/r/abgdiv17ztqnh...@gondor.apan
