CONFIG_DEBUG_SLAB and non-cache coherent CPUs
Eugene Surovegin
ebs at ebshome.net
Sun Feb 12 11:32:53 EST 2006
Hi!
I just wanted to let people on this list know that turning slab
debugging may cause slab corruption on non-coherent cache CPUs (4xx,
8xx).
The reason for this is that usually drivers which use DMA assume
L1 cache line alignment for buffers (e.g. returned from alloc_skb).
Unfortunately, with slab debugging enabled this is no longer the case,
and during cache invalidates we corrupt slab cache (or at least slab
poison markers).
I tried to define ARCH_KMALLOC_MINALIGN and/or ARCH_SLAB_MINALIGN but
it didn't work (and even if it did, it'd effectively disabled slab
debugging anyway).
I don't understand why slab debugging feature has to change allocation
alignment, as it can be obviously implemented without breaking this
alignment. Probably the reason is the usual one - nobody cares/cared
about non-coherent cache CPUs and saving couple of bytes was more
important :).
Anyway, I made a hack for my EMAC driver:
http://kernel.ebshome.net/emac_slab_debug.diff
which helps with this problem, although other drivers may experience
the same problem when used on 4xx/8xx with slab debugging enabled. In
fact, 3COM 905 driver crashed Ocotea in this configuration too.
--
Eugene
More information about the Linuxppc-embedded
mailing list