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

[Kees Cook]

On Mon, Oct 12, 2026 at 11:19:01PM +0200, Vlastimil Babka (SUSE) wrote:
> 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:
> >> > 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?

Right, the whole point of kmem_buckets was to replace general kmalloc
uses, where no callers cared about alignment.

> ctor removal is clear I think

Completely. I was blinded by the API of kmem_cache_create(). :)

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

Okay. (We have no users of this yet, FWIW.)

> SLAB_ACCOUNT requires __GFP_ACCOUNT, memcg objexts are always created and used

Right.

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

I think it's fine from studying what happens with the skb data. Though
right now, SLAB_ACCOUNT and SLAB_MAY_ACCOUNT are functionally identical,
yes?

> __GFP_ACCOUNT without either SLAB_ACCOUNT or SLAB_MAY_ACCOUNT is wrong,
> __GFP_ACCOUNT would be ignored

*ignored* is, I think, wrong here. It would create differing behavior
between SLAB_BUCKETS=y/n. If we passed __GFP_ACCOUNT through to general
kmalloc when the buckets lacked SLAB_ACCOUNT and SLAB_MAY_ACCOUNT, you'd
lose the isolation, but not the accounting. (And could WARN_ONCE about
it.) But if it was ignored, you'd lose accounting under
SLAB_BUCKETS=y.

> 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

Agreed. That's what I was going for on this version. But like above,
"SLAB_ACCOUNT requires __GFP_ACCOUNT" means what? Under SLAB_BUCKETS=y
the allocation returns NULL? Or it passes through with WARN_ONCE? I'd
rather not break something completely; better to fallback on a mismatch
so the requested type happens (be it DMA, ACCOUNTing, etc).

-- 
Kees Cook