On Fri, Jan 13, 2012 at 12:02:55PM +0100, Steffen Klassert wrote:
>
> If we want to do dynamic memory allocation, we could place it to the
> shash_desc context where we already store the intermediate digest value.
> This is preallocated anyway, so we don't need to do another allocation.
The proble
On Sat, Jan 14, 2012 at 09:27:37PM +0300, Alexey Dobriyan wrote:
> commit f9e2bca6c22d75a289a349f869701214d63b5060
> aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
> created global message schedule area.
>
> If sha512_update will ever be entered twice, hash will be silent
Le samedi 14 janvier 2012 à 13:52 -0800, Linus Torvalds a écrit :
> On Sat, Jan 14, 2012 at 1:46 PM, Eric Dumazet wrote:
> >
> > This is too risky, and we provided an alternate patch, not just for fun.
>
> Did you see the second patch?
>
I saw it and felt it was not a stable material.
And Herb
On Sat, Jan 14, 2012 at 1:46 PM, Eric Dumazet wrote:
>
> This is too risky, and we provided an alternate patch, not just for fun.
Did you see the second patch?
The one that got rid of the *stupid* 80-entry array?
I don't know why so many sha implementations do that idiotic full
array, when the
Le samedi 14 janvier 2012 à 21:27 +0300, Alexey Dobriyan a écrit :
> commit f9e2bca6c22d75a289a349f869701214d63b5060
> aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
> created global message schedule area.
> Signed-off-by: Alexey Dobriyan
> Cc: sta...@vger.kernel.org
>
On Sat, Jan 14, 2012 at 12:41 PM, Alexey Dobriyan wrote:
>
> For the record, it generates "andl $15" here.
Ok. That means that gcc was able to prove that it never had any signed
values (which is certainly reasonable when you do things like "for
(i=0; i Here is updated patch which explicitly uses
On Sat, Jan 14, 2012 at 11:08:45AM -0800, Linus Torvalds wrote:
> On Sat, Jan 14, 2012 at 10:40 AM, Alexey Dobriyan wrote:
> >
> > Line by line explanation:
> > * BLEND_OP
> > array is "circular" now, all indexes have to be modulo 16.
> > Round number is positive, so remainder operation should b
On Sat, Jan 14, 2012 at 10:40 AM, Alexey Dobriyan wrote:
>
> Line by line explanation:
> * BLEND_OP
> array is "circular" now, all indexes have to be modulo 16.
> Round number is positive, so remainder operation should be
> without surprises.
Don't use "%" except on unsigned values. Even if it
For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i -
16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.
Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).
Line by line explan
Use standard ror64() instead of hand-written.
There is no standard ror64, so create it.
The difference is shift value being "unsigned int" instead of uint64_t
(for which there is no reason). gcc starts to emit native ROR instructions
which it doesn't do for some reason currently. This should make
commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.
If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.
Probably the easiest way to notice incorrect ha
On Fri, Jan 13, 2012 at 01:34:13PM +0100, Eric Dumazet wrote:
> Le vendredi 13 janvier 2012 à 13:33 +0200, Alexey Dobriyan a écrit :
> > On 1/13/12, Eric Dumazet wrote:
> >
> > > + static u64 msg_schedule[80];
> > > + static DEFINE_SPINLOCK(msg_schedule_lock);
> >
> > No guys, no.
> >
> > SHA-5
12 matches
Mail list logo
