SLOB breaks Crypto
in [Kernel]
|
Prev: [RELEASE] LTTng 0.214 for kernel 2.6.33.4
Next: vlynq: make whole Kconfig-menu dependant on architecture
From: Herbert Xu on 19 May 2010 09:00 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 <herbert(a)gondor.apana.org.au> Thanks! -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert(a)gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Mackall on 19 May 2010 10:20 On Wed, 2010-05-19 at 13:50 +0200, Geert Uytterhoeven wrote: > On Wed, May 19, 2010 at 13:40, David Woodhouse <dwmw2(a)infradead.org> 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 value? > > > > What is 'correct'? The architecture sets it to the minimum value that it > > can cope with, according to its own alignment constraints (and DMA/cache > > constraints, in the case of ARCH_KMALLOC_MINALIGN). > > > > Some architectures don't _have_ any minimum required alignment, so they > > have no need to set it. If the architecture _does_ specify a minimum, > > the allocators must honour it. Otherwise, they're free to do their own > > thing. And slob chooses to use a smaller alignment than slab and slub > > do, in accordance with its design and its raison d'être. > > Currently 7 out of 20+ architectures set it. > Any bets on how many are missing, but should set it? 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. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 19 May 2010 11:30 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 to punish SLOB for the assumptions that SLAB/SLUB > > arbitrarily took up, presumably on an architecture that should have > > specified its own alignment requirements and simply couldn't be bothered. > > Making SLAB redzoning work with arbitrary alignment is another matter > > entirely, and something that should probably be revisited. > > > > Anything that assumes more than BYTES_PER_WORD is simply broken and > > should be reverted. 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. It is the *compiler* who tells us that long long needs to be aligned at double word boundaries. If an arch does not require long long alignment on double word boundaries then the *compiler* should tell us that and then the allocators will align on word boundaries. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 19 May 2010 15:40 From: Matt Mackall <mpm(a)selenic.com> 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 to suggest that we break all architectures not setting it now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 19 May 2010 15:50
From: David Woodhouse <dwmw2(a)infradead.org> 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 <penberg(a)cs.helsinki.fi> >> >> 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_MINALIGN before > the crypto one is applied. > > Although arguably SLOB was broken on sparc32 even before the crypto > patch -- so perhaps that fix shouldn't _have_ to go in first? Don't worry about sparc, I'll take care of it side-band. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |