Thread (23 messages) 23 messages, 5 authors, 1d ago

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

From: Pedro Falcato <pfalcato@suse.de>
Date: 2026-09-22 10:20:58
Also in: linux-hardening, linux-mm, lkml

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help