On 11/22/18 9:23 AM, Christoph Hellwig wrote:

On Wed, Nov 21, 2018 at 10:26:26PM +0000, Robin Murphy wrote:

quoted

TBH, if this DMA32 stuff is going to be contentious we could possibly just
rip out the offending kmem_cache - it seemed like good practice for the
use-case, but provided kzalloc(SZ_1K, gfp | GFP_DMA32) can be relied upon to
give the same 1KB alignment and chance of succeeding as the equivalent
kmem_cache_alloc(), then we could quite easily make do with that instead.

Neither is the slab support for kmalloc, not do kmalloc allocations
have useful alignment apparently (at least if you use slub debug).

Is this also true for caches created by kmem_cache_create(), that
debugging options can result in not respecting the alignment passed to
kmem_cache_create()? That would be rather bad, IMHO.

But I do agree with the sentiment of not wanting to spread GFP_DMA32
futher into the slab allocator.

I don't see a problem with GFP_DMA32 for custom caches. Generic
kmalloc() would be worse, since it would have to create a new array of
kmalloc caches. But that's already ruled out due to the alignment.

I think you want a simple genalloc allocator for this rather special
use case.

I would prefer if slab could support it, as it doesn't have to
preallocate. OTOH if the allocations are GFP_ATOMIC as suggested later
in the thread, and need to always succeed, then preallocation could be
better, and thus maybe genalloc.