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
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, 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,
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
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 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
Hi David,
On Wed, May 19, 2010 at 1:40 AM, David Miller wrote:
> I don't even know of a 32-bit chip outside of x86 that doesn't
> potentially emit alignment requiring 64-bit memory operations for
> 64-bit objects. So what SLOB is doing with a different default is
> even more strange. And I bet
Hi David,
On Wed, May 19, 2010 at 12:20 AM, David Miller wrote:
>> Why? It doesn't make much sense for SLOB, which tries to be as space
>> efficient as possible, as a default. If things break on sparc, it
>> really needs to set ARCH_KMALLOC_MINALIGN as slab default alignment is
>> not something y
On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
>
> I'll add the define for sparc, but saying "sparc's fault" is bogus
> because I defined what was necessary to get SLAB/SLUB to provide the
> necessary alignment. SLOB pays for choosing not to use the same
> calculations for minimum
On Tue, May 18, 2010 at 09:32:54PM +0200, Adrian-Ken Rueegsegger wrote:
>
> When doing the revert it is necessary to either have
> ARCH_KMALLOC_MINALIGN defined or explicitly define CRYPTO_MINALIGN in
> the case where it is not. Otherwise shash compilation fails because it
> needs CRYPTO_MINALIGN.
On Wed, May 19, 2010 at 12:20:34AM +0100, David Woodhouse wrote:
>
> It would be better if the minimum alignment was exposed to generic code
> though -- you're right that the CPP tests in linux/crypto.h really
> shouldn't have to exist. If it wasn't for that, then the crypto problem
> wouldn't hav
On Tue, 2010-05-18 at 14:20 -0700, David Miller wrote:
> I think it does make sense to expect that, whatever my architecture
> defines or does not define, I can expect the allocators to provide the
> same minimum alignment guarentee.
In a sense, they do. The minimum alignment guarantee is sizeof(l
On Tue, 2010-05-18 at 15:40 -0700, David Miller wrote:
> All of the CPP tests like the one used by linux/crypto.h are
> ludicrious. It should absolutely be not necessary for any code to
> duplicate this kind of calculation.
>
> Instead, this sequence should be in linux/slab.h, and be used
> unive
On Tue, May 18, 2010 at 03:40:59PM -0700, David Miller wrote:
> From: Paul Mundt
> Date: Wed, 19 May 2010 07:35:10 +0900
>
> > On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
> >> So one of two things should happen:
> >>
> >> 1) SLOB conforms to SLAB/SLUB in it's test
> >>
> >> 2)
From: Paul Mundt
Date: Wed, 19 May 2010 07:35:10 +0900
> On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller 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, yo
On Tue, May 18, 2010 at 09:32:54PM +0200, Adrian-Ken Rueegsegger wrote:
>
> When doing the revert it is necessary to either have
> ARCH_KMALLOC_MINALIGN defined or explicitly define CRYPTO_MINALIGN in
> the case where it is not. Otherwise shash compilation fails because it
> needs CRYPTO_MINALIGN.
(adding Christoph and dwmw2 to the Cc..)
On Wed, May 19, 2010 at 07:35:07AM +0900, Paul Mundt wrote:
> On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
> > From: Pekka Enberg
> > Date: Wed, 19 May 2010 00:15:46 +0300
> >
> > > On Tue, May 18, 2010 at 11:59 PM, David Miller
> > > w
On Tue, May 18, 2010 at 02:20:21PM -0700, David Miller wrote:
> From: Pekka Enberg
> Date: Wed, 19 May 2010 00:15:46 +0300
>
> > On Tue, May 18, 2010 at 11:59 PM, David Miller wrote:
> >> From: Matt Mackall
> >> Date: Tue, 18 May 2010 14:33:55 -0500
> >>
> >>> SLOB honors ARCH_KMALLOC_MINALIGN.
From: Pekka Enberg
Date: Wed, 19 May 2010 00:15:46 +0300
> On Tue, May 18, 2010 at 11:59 PM, David Miller wrote:
>> From: Matt Mackall
>> Date: Tue, 18 May 2010 14:33:55 -0500
>>
>>> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
>>> requirements, I recommend you set it.
>>
>> I
Hi David,
On Tue, May 18, 2010 at 11:59 PM, David Miller wrote:
> From: Matt Mackall
> Date: Tue, 18 May 2010 14:33:55 -0500
>
>> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
>> requirements, I recommend you set it.
>
> I recommend that the alignment provided by the allocator is
From: Matt Mackall
Date: Tue, 18 May 2010 14:33:55 -0500
> SLOB honors ARCH_KMALLOC_MINALIGN. If your arch has alignment
> requirements, I recommend you set it.
I recommend that the alignment provided by the allocator is not
determined by which allocator I happen to have enabled.
The values and
On Tue, 2010-05-18 at 12:25 -0700, David Miller wrote:
> From: Herbert Xu
> Date: Tue, 18 May 2010 20:27:01 +1000
>
> > I think the simplest fix is to revert this changeset.
>
> If you revert then you'll break sparc.
>
> Sparc needs long long alignment, so it's SLOB that needs to
> change if it
Herbert Xu wrote:
> On Tue, May 18, 2010 at 10:17:35AM +0200, Adrian-Ken Rueegsegger wrote:
>> As noted in my other mail [1] it seems like the HMAC tests trigger these
>> errors.
>
> Thanks for all the detective work!
>
> I think the problem is this changeset:
>
> commit 6eb7228421c01ba48a6a88a7
From: Herbert Xu
Date: Tue, 18 May 2010 20:27:01 +1000
> I think the simplest fix is to revert this changeset.
If you revert then you'll break sparc.
Sparc needs long long alignment, so it's SLOB that needs to
change if it isn't providing at least that much alignment
by default.
--
To unsubscri
On Tue, 2010-05-18 at 20:27 +1000, Herbert Xu wrote:
> On Tue, May 18, 2010 at 10:17:35AM +0200, Adrian-Ken Rueegsegger wrote:
> >
> > As noted in my other mail [1] it seems like the HMAC tests trigger these
> > errors.
>
> Thanks for all the detective work!
>
> I think the problem is this chang
Herbert Xu wrote:
On Tue, May 18, 2010 at 10:17:35AM +0200, Adrian-Ken Rueegsegger wrote:
As noted in my other mail [1] it seems like the HMAC tests trigger these
errors.
Thanks for all the detective work!
I think the problem is this changeset:
commit 6eb7228421c01ba48a6a88a7a5b3e71cfb70d4a9
On Tue, May 18, 2010 at 10:17:35AM +0200, Adrian-Ken Rueegsegger wrote:
>
> As noted in my other mail [1] it seems like the HMAC tests trigger these
> errors.
Thanks for all the detective work!
I think the problem is this changeset:
commit 6eb7228421c01ba48a6a88a7a5b3e71cfb70d4a9
Author: Herber
Matt Mackall schrieb:
> On Mon, 2010-05-17 at 23:50 +0200, Adrian-Ken Rueegsegger wrote:
>> Geert Uytterhoeven wrote:
>>> On Fri, Mar 19, 2010 at 02:33, Herbert Xu
>>> wrote:
On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
> Pekka Enberg schrieb:
>> Even wi
On Mon, 2010-05-17 at 23:50 +0200, Adrian-Ken Rueegsegger wrote:
> Geert Uytterhoeven wrote:
> > On Fri, Mar 19, 2010 at 02:33, Herbert Xu
> > wrote:
> >> On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
> >>> Pekka Enberg schrieb:
> Even with CONFIG_DEBUG_SLAB enab
Geert Uytterhoeven wrote:
> On Fri, Mar 19, 2010 at 02:33, Herbert Xu wrote:
>> On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
>>> Pekka Enberg schrieb:
Even with CONFIG_DEBUG_SLAB enabled or with CONFIG_SLUB and
CONFIG_SLUB_DEBUG_ON?
>>> no, these options hav
On Fri, Mar 19, 2010 at 02:33, Herbert Xu wrote:
> On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
>>
>> Pekka Enberg schrieb:
>> > Even with CONFIG_DEBUG_SLAB enabled or with CONFIG_SLUB and
>> > CONFIG_SLUB_DEBUG_ON?
>>
>> no, these options have not been / are not enab
Hi,
Herbert Xu wrote:
> On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
>> Pekka Enberg schrieb:
>>> Even with CONFIG_DEBUG_SLAB enabled or with CONFIG_SLUB and
>>> CONFIG_SLUB_DEBUG_ON?
>> no, these options have not been / are not enabled.
>
> Can you please try it wit
On Thu, Mar 18, 2010 at 10:24:41PM +0100, michael-...@fami-braun.de wrote:
>
> Pekka Enberg schrieb:
> > Even with CONFIG_DEBUG_SLAB enabled or with CONFIG_SLUB and
> > CONFIG_SLUB_DEBUG_ON?
>
> no, these options have not been / are not enabled.
Can you please try it with those options enabled?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pekka Enberg schrieb:
> Even with CONFIG_DEBUG_SLAB enabled or with CONFIG_SLUB and
> CONFIG_SLUB_DEBUG_ON?
no, these options have not been / are not enabled.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with
On Mon, Mar 15, 2010 at 3:39 PM, wrote:
> Hi,
>
> I've been trying to get Linux Kernel Crypto up&running
> on an AMD Geode LX board (Alix 2d2) but instantly
> experienced a huge amount of errors that look much like
> general memory corruption. Among them where NULL-pointer errors in
> net/core/ds
52 matches
Mail list logo
