From: netdev-bot+sashiko@kernel.org
To: kees@kernel.org
Cc: vbabka@kernel.org, harry@kernel.org, akpm@linux-foundation.org,
hao.li@linux.dev, cl@gentwo.org, rientjes@google.com,
roman.gushchin@linux.dev, linux-mm@kvack.org, pfalcato@suse.de,
kuniyu@google.com, linux-hardening@vger.kernel.org,
davem@davemloft.net, hannes@cmpxchg.org, mhocko@kernel.org,
shakeel.butt@linux.dev, muchun.song@linux.dev,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, kerneljasonxing@gmail.com, willemb@google.com,
almasrymina@google.com, bjorn@kernel.org, jiayuan.chen@linux.dev,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v5 3/7] mm/slab: Add kmem_buckets_destroy()
Date: Sat, 03 Oct 2026 23:13:17 +0000 [thread overview]
Message-ID: <179106919785.434549.14247431491192293062@kernel.org> (raw)
In-Reply-To: <20261002231132.1646573-3-kees@kernel.org>
Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] The new comment in kmem_buckets_destroy() (mm/slab_common.c)
says: "Sizes below arch_slab_minalign() share one cache, which…
--
mm/slab: Add kmem_buckets_destroy()
This adds kmem_buckets_destroy() as a counterpart to kmem_buckets_create(),
so that KUnit tests built as modules can tear down a bucket set. The
create path's bitmap-based error unwinding is replaced with a call to the
new helper. The helper clears every aliased pointer to a cache before
destroying it.
Link: https://lore.kernel.org/all/20240809073309.2134488-1-kees@kernel.org/
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 71926f726a07a..bdc34a5e6d6f5 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
[ ... ]
> +void kmem_buckets_destroy(kmem_buckets *bucket)
> +{
> + unsigned int idx, i;
> +
> + if (!IS_ENABLED(CONFIG_SLAB_BUCKETS) || ZERO_OR_NULL_PTR(bucket))
> + return;
> +
> + for (idx = 0; idx < ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]); idx++) {
> + struct kmem_cache *cache = (*bucket)[idx];
> +
> + if (!cache)
> + continue;
> +
> + /*
> + * Sizes below arch_slab_minalign() share one cache, which
> + * kmem_buckets_create() then stores at each of their indices.
[Severity: Low]
This isn't a bug, but is this comment accurate about where the aliasing
comes from?
The aliasing in kmalloc_caches[] is set up by new_kmalloc_cache(). It uses
__kmalloc_minalign(), and that is not arch_slab_minalign() on its own:
mm/slab_common.c:__kmalloc_minalign() {
unsigned int minalign = dma_get_cache_alignment();
...
return max(minalign, arch_slab_minalign());
}
new_kmalloc_cache() then rounds every size up to that alignment:
if (minalign > ARCH_KMALLOC_MINALIGN) {
aligned_size = ALIGN(aligned_size, minalign);
aligned_idx = __kmalloc_index(aligned_size, false);
}
This aliases sizes that are not multiples of minalign, even when they are
not below it. For example, kmalloc-96 maps to the 128 cache when minalign
is 64, and kmalloc-192 maps to the 256 cache when minalign is 128.
kmem_buckets_create() reads object_size from the already-aliased
kmalloc_caches[KMALLOC_NORMAL][idx], so the same aliasing ends up in the
bucket set.
The code itself is fine, because the inner loop clears every matching
pointer whatever caused the alias. Could the comment say that sizes are
rounded up to the kmalloc minimum alignment, rather than "sizes below
arch_slab_minalign()"?
The same wording also survives in the later commit "mm/slab: Let a
bucket set handle __GFP_ACCOUNT". That commit rewords this comment but
keeps "sizes below arch_slab_minalign() share one".
> + * Drop every reference to it before destroying it, so that no
> + * later pass reads a pointer to a cache that is already gone.
> + */
> + for (i = idx; i < ARRAY_SIZE(kmalloc_caches[KMALLOC_NORMAL]); i++)
> + if ((*bucket)[i] == cache)
> + (*bucket)[i] = NULL;
> +
> + kmem_cache_destroy(cache);
> + }
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261002231120.late.500-kees%40kernel.org
next prev parent reply other threads:[~2026-10-03 23:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 23:11 [PATCH net-next v5 0/7] net: skb: isolate skb data area allocations into a separate bucket Kees Cook
2026-10-02 23:11 ` [PATCH net-next v5 1/7] mm/slab: Mark the kmem_buckets_create() context as a Context: section Kees Cook
2026-10-02 23:11 ` [PATCH net-next v5 2/7] mm/slab: Let kmem_buckets_create() take an alignment Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko
2026-10-02 23:11 ` [PATCH net-next v5 3/7] mm/slab: Add kmem_buckets_destroy() Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko [this message]
2026-10-02 23:11 ` [PATCH net-next v5 4/7] mm/slab: Add tests for the existing kmem_buckets behaviour Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko
2026-10-02 23:11 ` [PATCH net-next v5 5/7] mm/slab: Provide kmalloc type fallback for bucket allocations Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko
2026-10-02 23:11 ` [PATCH net-next v5 6/7] mm/slab: Let a bucket set handle __GFP_ACCOUNT Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko
2026-10-02 23:11 ` [PATCH net-next v5 7/7] net: skb: isolate skb data area allocations into a separate bucket Kees Cook
2026-10-03 23:13 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=179106919785.434549.14247431491192293062@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=bjorn@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=horms@kernel.org \
--cc=jiayuan.chen@linux.dev \
--cc=kees@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pfalcato@suse.de \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@kernel.org \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®