On Tue, Sep 22, 2026 at 11:11:58AM +0100, Pedro Falcato wrote: > Big thanks for continuing this effort :))
Thanks for starting it! :) I've had a few folks wanting it, so I'm happy to help. > On Mon, Sep 21, 2026 at 12:58:16AM -0700, Kees Cook wrote: > [...] > > +/* > > + * The kmalloc types a bucket set can hold a copy of. This is deliberately > > not > > + * enum kmalloc_cache_type: the KMALLOC_PARTITION copies are all "normal" > > to a > > + * bucket set, which already separates what they were there to separate, so > > + * indexing by those would mean up to KMALLOC_PARTITION_CACHES_NR unusable > > + * rows per set. Allocations of any type not listed here are served by the > > + * general caches. > > + */ > > This sounds odd. Is there a good reason why KMALLOC_PARTITIONs are > kmalloc_cache_types? > Perhaps that bit should be reworked instead? I'm not sure I follow. Do you mean the partition copies themselves shouldn't be kmalloc_cache_types? That predates this series. For a bucket set, they're all the same "normal" type, so a set indexed by kmalloc_cache_type would carry rows it can never use: on x86_64 with CONFIG_KMALLOC_PARTITION_CACHES=y, that's 20 rows (2240 bytes) per set instead of 2 (224 bytes). I've put the numbers in the commit log for v5. > [...] > > + if (type <= KMALLOC_PARTITION_END) > > + btype = KMEM_BUCKET_NORMAL; > > + else > > + return &kmalloc_caches[type]; /* No set holds a row for it. */ > > Hitting this case sounds like a bug in the kernel. WARN_ON_ONCE()? The next patch warns where a set could have held the row but wasn't created with it (an accounted allocation without KMEM_BUCKET_CGROUP). What's left here are types no set can hold, like DMA and reclaimable, and those already come from caches of their own, so falling back doesn't lose the separation. > Otherwise LGTM. Thanks! -- Kees Cook
