Re: [PATCH v4 6/7] mm/slab: Let a bucket set handle __GFP_ACCOUNT

[Kees Cook]

On Tue, Sep 22, 2026 at 11:20:40AM +0100, Pedro Falcato wrote:
> On Mon, Sep 21, 2026 at 12:58:17AM -0700, Kees Cook wrote:
> > A bucket set holds one row of caches, cloned from KMALLOC_NORMAL, and an
> > allocation of any other kmalloc type falls back to the general caches.
> > Extend this to handle __GFP_ACCOUNT, so that a single bucket user can
> > isolate either GFP_KERNEL or GFP_KERNEL_ACCOUNT allocations, as is
> > needed for skb data, where AF_UNIX uses:
> > 
> > 	sk->sk_allocation = GFP_KERNEL_ACCOUNT;
> > 
> > The coverage is selected at bucket creation time:
> > 
> > 	b = kmem_buckets_create_types(name, flags, 0, INT_MAX, NULL,
> > 				      BIT(KMEM_BUCKET_NORMAL) |
> > 				      BIT(KMEM_BUCKET_CGROUP));
> > 
> > The prior kmem_buckets_create() function keeps its name and defaults
> > to only KMEM_BUCKET_NORMAL, leaving existing users as-is.
> > 
> > Only the accounted type is offered. Nothing wants a reclaimable or
> > no-obj-ext row, and of the twelve places passing GFP_DMA to an skb
> > allocator, all rare hardware: b44, b43legacy, prestera and s390 ctcm.
> 
> Well, yes, BUT I don't think silently falling back is a great option.
> I would rather things be done Properly(tm) and kmem_buckets allowing
> instantiation of most/all kmalloc cache types. Given it's security stuff,
> I would prefer being quite explicit over silent.

The types that fall back (DMA, reclaimable) are already isolated in
caches of their own, away from the normal ones, so the security goal
holds for them as-is. The one fallback that would undo the isolation,
an accounted allocation on a set made without the cgroup row, will
warn now.

-- 
Kees Cook