On Mon, Oct 12, 2026 at 11:03:18PM +0200, Vlastimil Babka (SUSE) wrote:
> On 10/12/26 19:55, Vlastimil Babka (SUSE) wrote:
> > On 10/6/26 11:20, 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.
> >>
> >> 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.
> >>
> >> 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 <[email protected]>
> >
> > Could we, for the purposes of a backportable fix, just have both
> > SLAB_ACCOUNT and GFP_KERNEL_ACCOUNT in place? That should do the right thing
> > regardless of CONFIG_SLAB_BUCKETS state, no?
>
> BTW we're thinking to add 1+2 (once this part is clarified) for 7.4 (with
> stable@ for patch 2).
Yeah, I'll respin with it present on the create and the alloc sides.
> But for the rest we'll have to target 7.5 as it's only
> a week to the 7.4 merge window now.
Yeah, that's totally fine; I'm in no rush. I want to get it right, and
I'm still recovering from my surprise about how GFP_KERNEL_ACCOUNT
actually works. ;)
--
Kees Cook
