From: sashiko-bot@kernel.org
To: "Breno Leitao" <leitao@debian.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Harry Yoo" <harry@kernel.org>, "Hao Li" <hao.li@linux.dev>,
"Christoph Lameter" <cl@gentwo.org>,
"David Rientjes" <rientjes@google.com>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Andrew Morton" <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, kernel-team@meta.com,
"Catalin Marinas" <catalin.marinas@arm.com>
Subject: Re: [PATCH] slab: allow sheaves for SLAB_NOLEAKTRACE caches
Date: Fri, 13 Nov 2026 10:05:08 +0000 [thread overview]
Message-ID: <sashiko-outbox-212599@kernel.org> (raw)
In-Reply-To: <20261112-kmemleak_sheaves-v1-1-e40e3d73b253@debian.org>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/slub: SLAB_ALLOC_NO_LEAKTRACE leaks into nested sheaf
allocations
--
commit 7da9d1d54f05d33de4e779dda137bfa95c2a403c
Author: Breno Leitao <leitao@debian.org>
slab: allow sheaves for SLAB_NOLEAKTRACE caches
This commit introduces SLAB_ALLOC_NO_LEAKTRACE so sheaves allocated for
SLAB_NOLEAKTRACE caches skip kmemleak tracking, allowing those caches to
use per-CPU sheaves without recursing into kmemleak.
Link: https://lore.kernel.org/all/aW_NK2NXVgtuzCVH@gmail.com/ [1]
> diff --git a/mm/slub.c b/mm/slub.c
> index 8369853ddca72..f19e20b6f9a4f 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2850,6 +2850,13 @@ static struct slab_sheaf *__alloc_empty_sheaf(struct kmem_cache *s, gfp_t gfp,
> if (s->flags & SLAB_KMALLOC)
> alloc_flags |= SLAB_ALLOC_NO_RECURSE;
>
> + /*
> + * kmemleak allocates its metadata from SLAB_NOLEAKTRACE caches, so
> + * tracking their sheaves would recurse into kmemleak.
> + */
> + if (s->flags & SLAB_NOLEAKTRACE)
> + alloc_flags |= SLAB_ALLOC_NO_LEAKTRACE;
> +
> sheaf_size = struct_size(sheaf, objects, capacity);
> sheaf = kmalloc_flags(sheaf_size, gfp | __GFP_ZERO, alloc_flags, NUMA_NO_NODE);
[Severity: Medium]
Does SLAB_ALLOC_NO_LEAKTRACE leak into nested sheaf and slabobj_ext
allocations for the backing normal kmalloc cache?
When s is a SLAB_NOLEAKTRACE cache (such as kmemleak's object_cache),
s->flags & SLAB_KMALLOC is false, so __alloc_empty_sheaf() passes
SLAB_ALLOC_NO_LEAKTRACE to kmalloc_flags() without SLAB_ALLOC_NO_RECURSE.
If the backing normal kmalloc bucket needs a new empty sheaf in
alloc_from_pcs() -> __pcs_replace_empty_main() -> alloc_empty_sheaf(),
that nested sheaf allocation inherits SLAB_ALLOC_NO_LEAKTRACE and is not
registered with kmemleak.
Because kmemleak never scans that untracked normal kmalloc sheaf:
- If the sheaf is later used as pcs->rcu_free in __kfree_rcu_sheaf(),
kvfree_call_rcu() returns before kmemleak_ignore(ptr) while freeing is
deferred, so kmemleak_scan() misses pcs->rcu_free->objects[] and reports
queued objects as false-positive leaks.
- Any tracked kmalloc sheaf linked between two untracked sheaves on
barn->sheaves_full or barn->sheaves_empty is unreachable during
kmemleak_scan() and is also reported as a false-positive leak.
- In slab_post_alloc_hook() -> alloc_tagging_slab_alloc_hook() ->
prepare_slab_obj_exts_hook() -> alloc_slab_obj_exts(), the slabobj_ext
vector is likewise allocated with SLAB_ALLOC_NO_LEAKTRACE still set,
skipping kmemleak registration before calling kmemleak_not_leak(vec).
Setting SLAB_ALLOC_NO_RECURSE along with SLAB_ALLOC_NO_LEAKTRACE (or
clearing SLAB_ALLOC_NO_LEAKTRACE before nested allocations) would prevent
the flag from propagating into the normal kmalloc cache's own metadata.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-kmemleak_sheaves-v1-1-e40e3d73b253@debian.org?part=1
prev parent reply other threads:[~2026-11-13 10:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 10:04 [PATCH] slab: allow sheaves for SLAB_NOLEAKTRACE caches Breno Leitao
2026-11-12 16:40 ` Catalin Marinas
2026-11-13 10:05 ` sashiko-bot [this message]
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=sashiko-outbox-212599@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vbabka@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.