Re: [PATCH net-next v6 2/8] ipc, msg: Account msg_msg allocations with GFP_KERNEL_ACCOUNT again

[Kees Cook]

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. :)

> 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.

> 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.

> > 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?

-- 
Kees Cook