On Mon, Oct 12, 2026 at 11:19:01PM +0200, Vlastimil Babka (SUSE) wrote: > 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: > >> > 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?
Right, the whole point of kmem_buckets was to replace general kmalloc uses, where no callers cared about alignment. > ctor removal is clear I think Completely. I was blinded by the API of kmem_cache_create(). :) > 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) Okay. (We have no users of this yet, FWIW.) > SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used Right. > 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? I think it's fine from studying what happens with the skb data. Though right now, SLAB_ACCOUNT and SLAB_MAY_ACCOUNT are functionally identical, yes? > __GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong, > __GFP_ACCOUNT would be ignored *ignored* is, I think, wrong here. It would create differing behavior between SLAB_BUCKETS=y/n. If we passed __GFP_ACCOUNT through to general kmalloc when the buckets lacked SLAB_ACCOUNT and SLAB_MAY_ACCOUNT, you'd lose the isolation, but not the accounting. (And could WARN_ONCE about it.) But if it was ignored, you'd lose accounting under SLAB_BUCKETS=y. > 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 Agreed. That's what I was going for on this version. But like above, "SLAB_ACCOUNT requires __GFP_ACCOUNT" means what? Under SLAB_BUCKETS=y the allocation returns NULL? Or it passes through with WARN_ONCE? I'd rather not break something completely; better to fallback on a mismatch so the requested type happens (be it DMA, ACCOUNTing, etc). -- Kees Cook
