Hi.
On Mon, Jun 02, 2008 at 02:06:03PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> it would be an issue if flush_cannel didn't save off the data required
> to call the callback with in saved_req. flush_channel does this on
> purpose to be able to call the callback outside of lock (as is
> c
Hi Sebastian:
On Mon, Jun 02, 2008 at 10:17:39PM +0200, Sebastian Siewior wrote:
>
> This is mpc8544 with gcc-4.1.1. The other powerpc machine I have
> available and could run a test is a ps3. Unfortunately I have to
> suspend this for two weeks.
> Arnd told me, that the powerpc folks were discus
Adrian-Ken Rueegsegger wrote:
> Neil Horman wrote:
>> On Sat, May 31, 2008 at 08:46:22AM +1000, Herbert Xu wrote:
>>> On Fri, May 30, 2008 at 07:26:38PM +0200, Adrian-Ken Rüegsegger wrote:
I was wondering why you created your own test vectors. Wouldn't
standardized test vectors by NIST o
On Mon, Jun 02, 2008 at 10:19:50PM +0200, Adrian-Ken Rueegsegger wrote:
> Neil Horman wrote:
> > On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
> >> On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
> >>> Copy that. I think I found the problem, anyway. The verdict is that
Neil Horman wrote:
> On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
>> On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
>>> Copy that. I think I found the problem, anyway. The verdict is that
>>> Adrian was
>>> right, and I'm klutz. I mixed up the output vector from a s
* Herbert Xu | 2008-05-26 21:05:08 [+1000]:
>Sebastian, if you're still seeing worse results on powerpc could you
>post the actual numbers with/without this patch?
le32:
~
|testing speed of rmd128
|test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):105
cycles/operation,6
On Mon, 2 Jun 2008 21:57:51 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > > But can it be changed? You write to it without lock, but read under the
> > > one (different for each channel though), so it at
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> > But can it be changed? You write to it without lock, but read under the
> > one (different for each channel though), so it attracted attention.
>
> can you point where in the code your concern is?
talitos_submi
On Mon, 2 Jun 2008 20:00:12 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > > I meant descriptor hdr value accessed via it - can it be checked in
> > > tasklet under the lock and in submit path without? Ca
On Mon, Jun 02, 2008 at 10:48:48PM +1000, Herbert Xu wrote:
> On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
> >
> > Copy that. I think I found the problem, anyway. The verdict is that
> > Adrian was
> > right, and I'm klutz. I mixed up the output vector from a successful and a
>
On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> > I meant descriptor hdr value accessed via it - can it be checked in
> > tasklet under the lock and in submit path without? Can they correlate
> > somehow?
>
> I believe the check for a non-null request->desc (un
On Sat, 31 May 2008 13:59:02 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > ok, I see what you are saying now; if a channel gets done during
> > talitos_done processing, it'll trigger an interrup
On Mon, Jun 02, 2008 at 06:32:10PM +1000, Herbert Xu wrote:
> On Mon, Jun 02, 2008 at 12:43:46AM +0200, Adrian-Ken Rueegsegger wrote:
> >
> > I just did a clean build on a different machine with the current HEAD
> > (ac3f925c2bb1b08a41713394d78098857d3f40a7)
> > of the cryptodev-2.6-tree. The two
On Mon, Jun 02, 2008 at 08:45:42AM -0400, Neil Horman wrote:
>
> Copy that. I think I found the problem, anyway. The verdict is that Adrian
> was
> right, and I'm klutz. I mixed up the output vector from a successful and a
> failed test during development. I'll repost shortly. Sorry for the t
Hi.
On Mon, Jun 02, 2008 at 11:08:59AM +0200, Eric Sesterhenn ([EMAIL PROTECTED])
wrote:
> i guess this shouldnt happen, got this
> when loading the tcrypt module
>
> [ 60.113277] testing ecb(seed) decryption across pages (chunking)
> [ 60.113309]
> [ 60.113311] testing cts(cbc(aes)) encr
On Mon, Jun 02, 2008 at 11:33:09AM +0200, Adrian-Ken Rueegsegger wrote:
> This patch fixes the usage of RIPEMD-160 in xfrm_algo which in turn
> allows hmac(rmd160) to be used as authentication mechanism in IPsec
> ESP and AH (see RFC 2857).
>
> Signed-off-by: Adrian-Ken Rueegsegger <[EMAIL PROTECT
This patch fixes the usage of RIPEMD-160 in xfrm_algo which in turn
allows hmac(rmd160) to be used as authentication mechanism in IPsec
ESP and AH (see RFC 2857).
Signed-off-by: Adrian-Ken Rueegsegger <[EMAIL PROTECTED]>
---
net/xfrm/xfrm_algo.c |4 ++--
1 files changed, 2 insertions(+), 2 de
This patch makes HMAC-RIPEMD-160 usable with IPsec/XFRM. The RIPEMD-160
implementation is currently in the cryptodev-2.6 tree.
Since I have no IPsec test setup the patch has not (yet) been tested with
IPsec and is thus marked as RFC. I will put together a test environment which
will take some time
Hi,
i guess this shouldnt happen, got this
when loading the tcrypt module
[ 60.113277] testing ecb(seed) decryption across pages (chunking)
[ 60.113309]
[ 60.113311] testing cts(cbc(aes)) encryption
[ 60.120984] test 1 (128 bit key):
[ 60.121153] [ cut here ]
[
On Mon, Jun 02, 2008 at 12:43:46AM +0200, Adrian-Ken Rueegsegger wrote:
>
> I just did a clean build on a different machine with the current HEAD
> (ac3f925c2bb1b08a41713394d78098857d3f40a7)
> of the cryptodev-2.6-tree. The two tests fail on that box too. :( I will see
> if I can spot something s
Hi Linus:
This push fixes a crash in CTS when SG debugging is enabled as
it doesn't set the debugging markers.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
Alexey Dobriyan (1):
On Mon, Jun 02, 2008 at 09:09:40AM +0200, Adrian-Ken Rueegsegger wrote:
>
> Ok thanks for the clarification. I will resubmit the patch to the addresses
> you specified.
> I assume linux-crypto should also be cc'd?
Yes please.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
Herbert Xu wrote:
> On Mon, Jun 02, 2008 at 09:02:08AM +0200, Adrian-Ken Rueegsegger wrote:
>> Yes, that would be the other way to do it. Is there a preference or specific
>> reason
>> for renaming the hash algorithm than changing the reference to the algorithm?
>
> I think the rmd name is fine.
On Mon, Jun 02, 2008 at 09:02:08AM +0200, Adrian-Ken Rueegsegger wrote:
>
> Yes, that would be the other way to do it. Is there a preference or specific
> reason
> for renaming the hash algorithm than changing the reference to the algorithm?
I think the rmd name is fine. The existing entry in IP
Sebastian Siewior wrote:
> * Adrian-Ken Rueegsegger | 2008-06-01 19:16:18 [+0200]:
>
>> This patch fixes the usage of RIPEMD-160 in xfrm_algo which in turn
>> allows hmac(rmd160) to be used as authentication mechanism in IPsec
>> ESP and AH (see RFC 2857).
>>
>> Signed-off-by: Adrian-Ken Rueegsegg
25 matches
Mail list logo
