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

[Harry Yoo <harry@kernel.org>]

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.

> 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

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

When it falls back to kmalloc, kmem_buckets itself should provide a
compatibility layer when falling back to kmalloc.
(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? :-)

> Build tested ARCH=x86_64 defconfig with GCC 16.2.0, with
> CONFIG_SLAB_BUCKETS as y and n.
> 
> Fixes: 734bbc1c97ea7 ("ipc, msg: Use dedicated slab buckets for alloc_msg()")
>
> Assisted-by: LLM
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  ipc/msgutil.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/ipc/msgutil.c b/ipc/msgutil.c
> index e28f0cecb2ec..1ba8e59cb255 100644
> --- a/ipc/msgutil.c
> +++ b/ipc/msgutil.c
> @@ -43,7 +43,7 @@ static kmem_buckets *msg_buckets __ro_after_init;
>  
>  static int __init init_msg_buckets(void)
>  {
> -	msg_buckets = kmem_buckets_create("msg_msg", SLAB_ACCOUNT,
> +	msg_buckets = kmem_buckets_create("msg_msg", 0,
>  					  sizeof(struct msg_msg),
>  					  DATALEN_MSG, NULL);
>  
> @@ -58,7 +58,8 @@ static struct msg_msg *alloc_msg(size_t len)
>  	size_t alen;
>  
>  	alen = min(len, DATALEN_MSG);
> -	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen, GFP_KERNEL);
> +	msg = kmem_buckets_alloc(msg_buckets, sizeof(*msg) + alen,
> +				 GFP_KERNEL_ACCOUNT);
>  	if (msg == NULL)
>  		return NULL;

-- 
Cheers,
Harry / Hyeonggon