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

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:

quoted

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