On Mon, Aug 8, 2011 at 1:48 PM, Locktyukhin, Maxim
wrote:
> 20 (and more) cycles per byte shown below are not reasonable numbers for SHA-1
> - ~6 c/b (as can be seen in some of the results for Core2) is the expected
> results ...
Ten years ago, on Pentium II, one benchmark showed 13 cycles/byte
From: Thomas Meyer
Date: Sat, 06 Aug 2011 10:26:25 +0200
> From: Thomas Meyer
>
> Fix a get/put_cpu() imbalance in the error case when qp == NULL
>
> Signed-off-by: Thomas Meyer
Acked-by: David S. Miller
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body
I'd like to note that at Intel we very much appreciate Mathias effort to
port/integrate this implementation into Linux kernel!
$0.02 re tcrypt perf numbers below: I believe something must be terribly broken
with the tcrypt measurements
20 (and more) cycles per byte shown below are not reasonab
On Sun, 7 Aug 2011, Linus Torvalds wrote:
> On Sun, Aug 7, 2011 at 1:48 PM, Joachim Eastwood wrote:
> >
> > yes, this works. At least my board boots as normal.
>
> Ok, I'll remove it for -rc1, just to have a working ARM setup. Maybe
> we can re-introduce it later (either together with some arm-
While not connected to ARM's implementation of sha_transform,
maybe this might make code a bit clearer.
Remove need to know the size and type of SHA_WORKSPACE_WORDS.
Introduce and use opaque struct sha_workspace instead.
Add #include to lib/sha1.c
Signed-off-by: Joe Perches
---
crypto/sha1_ge
On Sun, Aug 7, 2011 at 2:29 PM, Joe Perches wrote:
> While not connected to ARM's implementation of sha_transform,
> maybe this might make code a bit clearer.
>
> Remove need to know the size and type of SHA_WORKSPACE_WORDS.
> Introduce and use opaque struct sha_workspace instead.
The thing is, t
On Sun, Aug 7, 2011 at 1:48 PM, Joachim Eastwood wrote:
>
> yes, this works. At least my board boots as normal.
Ok, I'll remove it for -rc1, just to have a working ARM setup. Maybe
we can re-introduce it later (either together with some arm-specific
hack for SHA_WORKSPACE_WORDS or by having an a
On Sun, Aug 7, 2011 at 10:17 PM, Linus Torvalds
wrote:
> On Sun, Aug 7, 2011 at 12:47 PM, Andreas Schwab wrote:
>>
>> ARM has its own implementation of sha_transform in arch/arm/lib/sha1.S,
>> which assumes SHA_WORKSPACE_WORDS is 80.
>
> Well, that certainly explains it.
>
> I wonder if that thin
On Sun, Aug 7, 2011 at 12:47 PM, Andreas Schwab wrote:
>
> ARM has its own implementation of sha_transform in arch/arm/lib/sha1.S,
> which assumes SHA_WORKSPACE_WORDS is 80.
Well, that certainly explains it.
I wonder if that thing is worth it. It seems to be based on the bad
slow version of sha1
Joachim Eastwood writes:
> On Sun, Aug 7, 2011 at 8:38 PM, Linus Torvalds
> wrote:
>> There aren't many users of that define, could you just turn it back to the
>> proper 16, and then try changing it to 80 in each place that uses it?
>>
>> That way we'd see exactly *which* use is the buggy one.
On Sun, Aug 7, 2011 at 8:38 PM, Linus Torvalds
wrote:
> There aren't many users of that define, could you just turn it back to the
> proper 16, and then try changing it to 80 in each place that uses it?
>
> That way we'd see exactly *which* use is the buggy one..
Its drivers/char/random.c.
Boot
There aren't many users of that define, could you just turn it back to the
proper 16, and then try changing it to 80 in each place that uses it?
That way we'd see exactly *which* use is the buggy one..
Linus
Joachim Eastwood wrote:
>On Sun, Aug 7, 2011 at 7:44 PM, Linus Torvalds
> wr
On Sun, Aug 7, 2011 at 7:44 PM, Linus Torvalds
wrote:
> On Sun, Aug 7, 2011 at 10:36 AM, Joachim Eastwood wrote:
>>
>> These printk's come from drivers/char/random.c
>> So it doesn't seem like it hangs in any of the sha_* funtions.
>
> The only other change is to SHA_WORKSPACE_WORDS - I wonder i
On Sun, Aug 7, 2011 at 10:36 AM, Joachim Eastwood wrote:
>
> These printk's come from drivers/char/random.c
> So it doesn't seem like it hangs in any of the sha_* funtions.
The only other change is to SHA_WORKSPACE_WORDS - I wonder if some
code depends on the old (much bigger) workspace for some
On Sun, Aug 7, 2011 at 6:52 PM, Linus Torvalds
wrote:
> On Sun, Aug 7, 2011 at 4:54 AM, Joachim Eastwood wrote:
>>
>> I see some ARM asm in your patch, maybe this is the cause?
>
> No, it's just a barrier to make sure the compiler doesn't do crazy
> things, no actual asm instructions involved.
>
On Sun, Aug 7, 2011 at 4:54 AM, Joachim Eastwood wrote:
>
> I see some ARM asm in your patch, maybe this is the cause?
No, it's just a barrier to make sure the compiler doesn't do crazy
things, no actual asm instructions involved.
That code is quite well tested in git, so I'm surprised it has a
On Sat, Aug 6, 2011 at 3:46 AM, Mandeep Singh Baines wrote:
> For ChromiumOS, we use SHA-1 to verify the integrity of the root
> filesystem. The speed of the kernel sha-1 implementation has a major
> impact on our boot performance.
>
> To improve boot performance, we investigated using the heavily
17 matches
Mail list logo
