On Wed, May 19, 2010 at 03:24:24PM +0200, Shikhar wrote:
> Hi,
>
> I am currently working on a driver for our crypto HW and the initial
> aim was to offload IPSec (ESP for now) to HW. I did this by
> registering the cipher and hash algorithms (both asynchronous)
> separately (AES-CBC, HMAC-SHA1 on
From: FUJITA Tomonori
Date: Thu, 20 May 2010 12:38:01 +0900
> On Wed, 19 May 2010 12:33:25 -0700 (PDT)
> David Miller wrote:
>
>> From: Matt Mackall
>> Date: Wed, 19 May 2010 09:11:47 -0500
>>
>> > I still think we should add it to all of them as positive documentation
>> > that this issue ha
On Wed, 19 May 2010 12:33:25 -0700 (PDT)
David Miller wrote:
> From: Matt Mackall
> Date: Wed, 19 May 2010 09:11:47 -0500
>
> > I still think we should add it to all of them as positive documentation
> > that this issue has been considered. And then make the kernel not
> > compile without it so
From: Christoph Lameter
Date: Wed, 19 May 2010 10:19:33 -0500 (CDT)
> The assumptions are not arbitrary. It is reasonable to assume that
> structures managed by the slab allocators may contain long long variables
> and that therefore a unsigned long long alignment is required by the
> allocator.
From: Herbert Xu
Date: Wed, 19 May 2010 22:59:03 +1000
> On Wed, May 19, 2010 at 03:54:43PM +0300, Pekka Enberg wrote:
>>
>> OK, I'll pick up David's patches and just wait for sparc changes to
>> hit Linus' tree first. Herbert, do I have your ACK for the crypto
>> patches?
>
> Of course:
>
> Ac
On Wed, 19 May 2010, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > Maybe we can consolidate that into slab.h so that the alignment is the
> > same for all allocators?
>
> But we don't want that for SLOB as discussed in the other thread. It really
> wants to be sizeof(unsigned long), not sizeo
From: David Woodhouse
Date: Wed, 19 May 2010 12:16:45 +0100
> On Wed, 2010-05-19 at 14:08 +0300, Pekka Enberg wrote:
>>
>> Acked-by: Pekka Enberg
>>
>> Are you sending the patches to Linus or do you want me to pull them in
>> slab.git?
>
> I don't mind. Feel free to apply them to slab.git, b
From: Matt Mackall
Date: Wed, 19 May 2010 09:11:47 -0500
> I still think we should add it to all of them as positive documentation
> that this issue has been considered. And then make the kernel not
> compile without it so new arch implementors can't miss it.
I agree and would even go so far as
On Wed, 2010-05-19 at 14:19 -0500, Christoph Lameter wrote:
>
> Maybe we can consolidate that into slab.h so that the alignment is the
> same for all allocators?
Doing so at least for slub and slab would make sense. I wanted to move
them first though, as a separate step.
--
David Woodhouse
Maybe we can consolidate that into slab.h so that the alignment is the
same for all allocators?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Christoph Lameter wrote:
Maybe we can consolidate that into slab.h so that the alignment is the
same for all allocators?
But we don't want that for SLOB as discussed in the other thread. It
really wants to be sizeof(unsigned long), not sizeof(unsigned long long).
Pekk
David Woodhouse wrote:
Signed-off-by: David Woodhouse
I applied patches 1-4. Thanks David!
---
include/linux/slab_def.h | 24
mm/slab.c| 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/include/linux/s
On Wed, 2010-05-19 at 20:03 +0200, Manfred Spraul wrote:
> Is this text better?
Not really...
> * Unless debug options are enabled, the kernel uses cache_line_size()
> automatically.
... that's a lie.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@
On 05/19/2010 03:30 PM, Johannes Stezenbach wrote:
Hi,
I have some comments/questions, I hope it's not too silly:
On Wed, May 19, 2010 at 12:01:42PM +0100, David Woodhouse wrote:
+#ifndef ARCH_KMALLOC_MINALIGN
+/*
+ * Enforce a minimum alignment for the kmalloc caches.
+ * Usually, the kma
On Wed, 19 May 2010 14:49:08 +0100
David Woodhouse wrote:
> Commit 3843384a055496dfed3c93ae883d964d8290fdab ("Input: ad7877 - keep
> dma rx buffers in seperate cache lines")[sic] introduced the use of
> cacheline_aligned to ensure that buffers used for DMA as part of a
> structure were suitab
On Wed, 19 May 2010, Paul Mundt wrote:
> > > So one of two things should happen:
> > >
> > > 1) SLOB conforms to SLAB/SLUB in it's test
> > >
> > > 2) SLAB/SLUB conforms to SLOB in it's test
> > >
> > > And yes this is an either-or, you can't say they are both valid.
> >
> > I don't see any reason
On Wed, 2010-05-19 at 13:50 +0200, Geert Uytterhoeven wrote:
> On Wed, May 19, 2010 at 13:40, David Woodhouse wrote:
> > On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> >> Instead of having (different) defaults in sl[aou]b, perhaps we should
> >> just remove the defaults completely,
Commit 3843384a055496dfed3c93ae883d964d8290fdab ("Input: ad7877 - keep
dma rx buffers in seperate cache lines")[sic] introduced the use of
cacheline_aligned to ensure that buffers used for DMA as part of a
structure were suitably separated from the rest of the structure.
However, aligning to t
Hi,
I have some comments/questions, I hope it's not too silly:
On Wed, May 19, 2010 at 12:01:42PM +0100, David Woodhouse wrote:
> +#ifndef ARCH_KMALLOC_MINALIGN
> +/*
> + * Enforce a minimum alignment for the kmalloc caches.
> + * Usually, the kmalloc caches are cache_line_size() aligned, except
Hi,
I am currently working on a driver for our crypto HW and the initial
aim was to offload IPSec (ESP for now) to HW. I did this by
registering the cipher and hash algorithms (both asynchronous)
separately (AES-CBC, HMAC-SHA1 only for now) and let the API handle
the request using the AUTHENC inte
On Wed, May 19, 2010 at 03:54:43PM +0300, Pekka Enberg wrote:
>
> OK, I'll pick up David's patches and just wait for sparc changes to
> hit Linus' tree first. Herbert, do I have your ACK for the crypto
> patches?
Of course:
Acked-by: Herbert Xu
Thanks!
--
Visit Openswan at http://www.openswan.
On Wed, May 19, 2010 at 2:46 PM, Herbert Xu wrote:
> On Wed, May 19, 2010 at 12:16:45PM +0100, David Woodhouse wrote:
>>
>> I don't mind. Feel free to apply them to slab.git, but be aware that
>> Herbert wanted to see a patch fixing sparc32 ARCH_SLAB_MINALIGN before
>> the crypto one is applied.
>
On Wed, 2010-05-19 at 21:26 +0900, FUJITA Tomonori wrote:
>
> > Surely those architectures that have alignment constraints for DMA
> but
> > which don't set ARCH_KMALLOC_MINALIGN are just buggy -- it _does_
> mean
> > that.
>
> Well, I thought so but seems that there isn't such agreement:
>
> ht
On Wed, 19 May 2010 13:19:45 +0100
David Woodhouse wrote:
> On Wed, 2010-05-19 at 21:02 +0900, FUJITA Tomonori wrote:
> > On Wed, 19 May 2010 12:40:36 +0100
> > David Woodhouse wrote:
> >
> > > On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> > > > Instead of having (different) de
On Wed, 2010-05-19 at 21:02 +0900, FUJITA Tomonori wrote:
> On Wed, 19 May 2010 12:40:36 +0100
> David Woodhouse wrote:
>
> > On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> > > Instead of having (different) defaults in sl[aou]b, perhaps we should
> > > just remove the defaults com
On Wed, 19 May 2010 12:40:36 +0100
David Woodhouse wrote:
> On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> > Instead of having (different) defaults in sl[aou]b, perhaps we should
> > just remove the defaults completely, to ensure all architectures set
> > ARCH_SLAB_MINALIGN to the
On Wed, May 19, 2010 at 13:40, David Woodhouse wrote:
> On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
>> Instead of having (different) defaults in sl[aou]b, perhaps we should
>> just remove the defaults completely, to ensure all architectures set
>> ARCH_SLAB_MINALIGN to the correct
On Wed, May 19, 2010 at 12:16:45PM +0100, David Woodhouse wrote:
>
> I don't mind. Feel free to apply them to slab.git, but be aware that
> Herbert wanted to see a patch fixing sparc32 ARCH_SLAB_MINALIGN before
> the crypto one is applied.
>
> Although arguably SLOB was broken on sparc32 even befo
On Wed, May 19, 2010 at 09:14, David Woodhouse wrote:
> On Wed, 2010-05-19 at 11:05 +1000, Herbert Xu wrote:
>> While this problem wouldn't have occurred, we would instead have
>> data corruption/alignment faults on architectures such as sparc32
>> or ARM that require 64-bit alignment for 64-bit o
On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
> Instead of having (different) defaults in sl[aou]b, perhaps we should
> just remove the defaults completely, to ensure all architectures set
> ARCH_SLAB_MINALIGN to the correct value?
What is 'correct'? The architecture sets it to the
On Wed, 2010-05-19 at 14:08 +0300, Pekka Enberg wrote:
>
> Acked-by: Pekka Enberg
>
> Are you sending the patches to Linus or do you want me to pull them in
> slab.git?
I don't mind. Feel free to apply them to slab.git, but be aware that
Herbert wanted to see a patch fixing sparc32 ARCH_SLAB_M
On Wed, May 19, 2010 at 1:58 PM, David Woodhouse wrote:
> On Wed, 2010-05-19 at 11:05 +1000, Herbert Xu wrote:
>> So no getting rid of them isn't going to fix things either. Of
>> course I have no objections to moving this into slab.h or a similar
>> location should anyone be willing to do the ha
Signed-off-by: David Woodhouse
---
include/linux/slub_def.h |8
mm/slub.c|8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 0249d41..55695c8 100644
--- a/include/linux/slub_def.h
++
Signed-off-by: David Woodhouse
---
include/linux/crypto.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 24d2e30..a6a7a1c 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -99,13 +99,7 @@
* as
Signed-off-by: David Woodhouse
---
include/linux/slob_def.h |8
mm/slob.c|8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/slob_def.h b/include/linux/slob_def.h
index 0ec00b3..62667f7 100644
--- a/include/linux/slob_def.h
++
Signed-off-by: David Woodhouse
---
include/linux/slab_def.h | 24
mm/slab.c| 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index ca6b2b3..1812dac 100644
On Wed, 2010-05-19 at 11:05 +1000, Herbert Xu wrote:
> So no getting rid of them isn't going to fix things either. Of
> course I have no objections to moving this into slab.h or a similar
> location should anyone be willing to do the hard work.
http://git.infradead.org/users/dwmw2/minalign-2.6.gi
On Mon, May 03, 2010 at 06:43:21PM +, Kim Phillips wrote:
> SEC h/w versions 2.1 and above support sha224 via explicit instruction.
>
> Performing sha224 ahashes on earlier versions is still possible because
> they support sha256 (sha224 is sha256 with different initial constants
> and a diffe
On Sat, May 01, 2010 at 03:25:52AM +, Kim Phillips wrote:
> On Fri, 30 Apr 2010 07:21:23 -0500
> Lee Nipper wrote:
>
> > Add the following alorithms to talitos:
> > md5,
> > sha1,
> > sha256,
> > sha384,
> > sha512.
> > These are all type ahash.
> >
> > Signed-off-by: Lee
On Wed, May 19, 2010 at 08:14:28AM +0100, David Woodhouse wrote:
>
> Yeah, but that's what ARCH_SLAB_MINALIGN is for.
>
> ARM gets this right, and Dave has already said he's going to fix sparc.
Right, once that gets in I will fix crypto.h so that it'll work
correctly with SLOB.
Thanks,
--
Visit
On Wed, 2010-05-19 at 11:05 +1000, Herbert Xu wrote:
> While this problem wouldn't have occurred, we would instead have
> data corruption/alignment faults on architectures such as sparc32
> or ARM that require 64-bit alignment for 64-bit objects.
Yeah, but that's what ARCH_SLAB_MINALIGN is for.
A
41 matches
Mail list logo
