On 10/10/26 05:18, Kees Cook wrote: > On Fri, Oct 09, 2026 at 09:39:48PM +0200, Harry Yoo wrote: >> On Fri, Oct 09, 2026 at 04:22:03PM +0200, Harry Yoo wrote: >> > And now I see the initial kmem_buckets design did not sufficiently >> > tackle the question "How this should work when kmem_buckets falls back >> > to kmalloc?" >> > >> > I suppose the kmem_buckets' abstraction should not be too tightly >> > coupled with kmalloc caches. Creating a kmem_buckets should be >> > conceptually equivalent to creating a set of caches with speicifc >> > slab flags, size, align, useroffset/size. (for variable size allocation). >> >> Just to clarify... I have a few concerns on this area. >> >> 1. Complexity. >> >> It's very counter-intuitive to understand how it works when >> SLAB_BUCKETS is not compiled. My brain cannot easily process two >> different implementations w/ and w/o SLAB_BUCKETS. >> >> A "compatibility layer" allows us to assume certain expectations >> and ignore all implementation details when SLAB_BUCKETS is not compiled. > > I'd rather make kmem_buckets not have a SLAB_BUCKETS option. :)
The tradeoff hardening vs memory footprint exists however, so I don't think we can simply do that. >> 2. Making kmem_buckets tightly coupled with kmalloc's implementation >> details is not reasonable. >> >> Let's say, at some point we make SLAB_BUCKETS always enabled and drop >> the config option. Then all kmem_buckets users will now have certain >> assumptions inherted from kmalloc (e.g. alignment), which is not >> reasonable. > > Until it's always enabled, I don't see a reasonable way to separate > those assumptions. Agree. I don't think the assumptions are so problematic. >> 3. __GFP_ACCOUNT and __GFP_DMA should be applied to all allocations >> in the slab cache. For kmalloc, these flags are only used to select >> the kmalloc cache (which has equivalent SLAB_* flags for __GFP_ACCOUNT >> or __GFP_DMA) to serve the allocation. >> >> Specifying it on individual allocations (rather than as SLAB_ flags) >> makes it easy to break the assumption. > > As in, you don't want a "pass-through" mode for __GFP_DMA? > > It's a lot of overhead for __GFP_DMA to have multiple providers, so I'd > rather allow kmem_buckets to allow pass-through (perhaps explicitly > opt-in) where then the other options (e.g. alignment) must match the > general kmalloc caches so that pass-through is consistent. "pass-through" mode for __GFP_DMA seems reasonable to me. I hope we eventually get rid of it, so I would support it in the most simple way possible. >> > When it falls back to kmalloc, kmem_buckets itself should provide a >> > compatibility layer when falling back to kmalloc. >> >> For example, calculate_sizes() converts certain SLAB_* flags into >> GFP flags (s->allocflags) for allocation. We can have a similar >> logic when falling back to kmalloc. >> >> Though current implementation does not allow this and requires >> some rework. > > I think the current series does everything correctly in the sense that > nothing is allowing for mismatched fallbacks/passthrus. We could iterate > from there once we have a need for this where a non-kmalloc-alignment is > wanted, etc? I think we can indeed simply make sure buckets have the same alignment as kmalloc. It comes naturally and should (more than) satisfy everyone. I doubt anyone would be needing a more specific alignment than that for a class of allocations with a variable size? ctor removal is clear I think for __GFP_ACCOUNT and __GFP_RECLAIMABLE I think what we could do is not to drop the flags argument kmem_buckets_create and instead require that it matches the usage: __GFP_RECLAIMABLE requires SLAB_RECLAIM_ACCOUNT and vice versa and I can't imagine there would be a buckets instance that would allocate both kinds (either with or without __GFP_RECLAIMABLE) SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used SLAB_MAY_ACCOUNT allows __GFP_ACCOUNT, memcg objexts are always created, and used when __GFP_ACCOUNT given - perhaps not as optimal as the separate kmalloc types, but good enough? __GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong, __GFP_ACCOUNT would be ignored with SLAB_BUCKETS=y these rules could be checked e.g. with a VM_WARN_ON_ONCE() with SLAB_BUCKETS=n these rules won't be checked but also not matter in practice wdyt?
