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

[Kees Cook <kees@kernel.org>]

On Fri, Oct 09, 2026 at 04:22:01PM +0200, Harry Yoo wrote:
> On Tue, Oct 06, 2026 at 02:20:28AM -0700, Kees Cook wrote:
> > Since commit 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for
> > alloc_msg()"), alloc_msg() allocates with GFP_KERNEL, and a msg_msg is
> > accounted only through SLAB_ACCOUNT on its bucket caches.
> 
> > With
> > CONFIG_SLAB_BUCKETS=n, kmem_buckets_create() creates no caches and
> > kmem_buckets_alloc() is a GFP_KERNEL kmalloc() from the general caches,
> > which do not account it; the same happens when kmem_buckets_create()
> > fails. Either way, the allocation is not charged to the sender's memory
> > cgroup.
> 
> Ouch, now I see what's gone wrong here... 
> The fix for this bug should be Cc: stable IMHO.
> Allowing to escape memcg charging is not good.

Anything with Fixes: will end up in stable, so I just leave off the
stable CC these days.

> > Allocate with GFP_KERNEL_ACCOUNT again, as before that commit. Memcg
> > charges such an allocation in whichever cache serves it, so drop the
> > SLAB_ACCOUNT, which no longer adds anything.
> 
> Hmm in the long term we don't want allowing __GFP_ACCOUNT allocations
> that are served from slab caches without SLAB_ACCOUNT, as this wastes
> memory.
> 
> See: https://lore.kernel.org/linux-mm/20260720-b4-objext_split-v2-0-2fa7c6f60dbe@kernel.org

This is how I thought things worked, so my original version of this
series kept separate caches. (I can return to that too, but it doesn't
seem to be needed today?)

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

Right. We could just make kmem_buckets non-optional, too? Then they
could have all the caller personalization they need.

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

In my mind, the general kmalloc caches are just a specific instance of a
kmem_buckets...

> When it falls back to kmalloc, kmem_buckets itself should provide a
> compatibility layer when falling back to kmalloc.

IMO, it'd just be better to make kmem_buckets not NEED a compat layer...

> (Okay, allowing ctor is completely broken, but other attributes are fine)
> 
> ...I don't agree with the idea that "since kmem_buckets can fall back to
> kmalloc, kmem_buckets can only have the same requirements as kmalloc
> (slab flags, alignment, etc.)".
> 
> By that logic, shouldn't we give up specifying useroffset and usersize
> too? :-)

Yup, but I kept that since only the hardening guarantees change under
that condition -- nothing operationally depends on useroffset/size.

-Kees

-- 
Kees Cook