CONFIG_DEBUG_SLAB and non-cache coherent CPUs

CONFIG_DEBUG_SLAB and non-cache coherent CPUs

[Eugene Surovegin]

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