All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.