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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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?