Re: [BUG] slab debug vs. L1 alignement

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> >
> >Yes, I understand that, but that is wrong for GFP_DMA imho. Also, 
> >SLAB_MUST_HWCACHE_ALIGN just disables redzoning, which is not smart,
> >I'd rather allocate more and keep both redzoning and cache alignement,
> >that would help catch some of those subtle problems when a chip DMA
> >engine plays funny tricks.
> >
> I don't want to upgrade SLAB_HWCACHE_ALIGN to SLAB_MUST_HWCACHE_ALIGN 
> depending on GFP_DMA: IIRC one arch (ppc64?) marks everything as 
> GFP_DMA, because all memory is DMA capable.

Same for ppc32. Anyway, I don't like MUST_HWCACHE_ALIGN because it
just disables redzoning, I'd rather allocate more and do both redzoning
and cache alignement.

In fact, I think cache alignement should be a property of all kmalloc
calls for any size > L1 cache line size for obvious perfs reasons, and
redzoning shouldn't change such a property...

> Which arch do you use? Perhaps alignment could be added for broken archs.
> 
> Actually I think you should fix your arch, perhaps by double buffering 
> in pci_map_ if the input pointers are not aligned. What if someone uses 
> O_DIRECT with an unaligned pointer?

ppc32 "normally" is cache coherent, that is with high end or desktop CPUs,
embedded CPUs aren't. Some archs like ARM arent't. But in this case, the
problem is related to a broken SCSI controller on the motherboard which
will cause corruption on non-aligned buffers (it basically always issues
memory write and invalidate cycles).

Anyway, I _still_ think it's stupid to return non-aligned buffers, both
for performances, and because that prevents from dealing with such cases,
typically the SCSI layer assumes alignement here among others...

Regarding O_DIRECT with an unaligned pointer, I haven't looked at this
case yet, I suppose it will be broken in a whole lot of cases.

Ben.