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

[Pedro Falcato]

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.

Perhaps, to save on memory, users could choose to fall back to the default
caches. But at kmem_buckets_create time.


-- 
Pedro