I have a patch that creates helper functions that make that simple. The patch is stuck right now, because it exposes a bug in the i386 debug register handling. I'll add it redzoning with MUST_HWCACHE_ALIGN after that one is in.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 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.
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.
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.
Anyway, I _still_ think it's stupid to return non-aligned buffers, bothI don't care about performance with slab debugging on. kmalloc(4096,) usually takes ~40 cpu ticks on i386. With debugging on, it includes a memset and an open coded memcmp - my guess is a few thousand cpu ticks, and that's intentional. Do not enable it on production systems.
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 thisHmm. That means slab debugging did it's job: The driver contains the wrong assumption that all pointers are cache line aligned. Without slab debugging, this would result in rare data corruptions in O_DIRECT apps. With slab debugging on, it's exposed immediately.
case yet, I suppose it will be broken in a whole lot of cases.