From: Breno Leitao <leitao@debian.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: sashiko-reviews@lists.linux.dev,
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>,
linux-mm@kvack.org, kernel-team@meta.com
Subject: Re: [PATCH] slab: allow sheaves for SLAB_NOLEAKTRACE caches
Date: Fri, 13 Nov 2026 06:21:16 -0800 [thread overview]
Message-ID: <avcb-W5ZOWqI9SbN@gmail.com> (raw)
In-Reply-To: <avcCGNUqCrcwbFG6@arm.com>
On Fri, Nov 13, 2026 at 12:27:04PM +0000, Catalin Marinas wrote:
> On Fri, Nov 13, 2026 at 10:05:08AM +0000, sashiko-bot@kernel.org wrote:
> >
> > 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 is right here, this could lead to false positives. I don't think
> clearing SLAB_ALLOC_NO_LEAKTRACE before nested allocations is correct
> since that could reintroduce the original recursion. Adding
> SLAB_ALLOC_NO_RECURSE alongside it should fix this.
ack. I will respin v2 and sets both flags for SLAB_NOLEAKTRACE caches.
> IIUC, I think we need to include SLAB_NOLEAKTRACE in the
> mark_obj_codetag_empty() condition in __free_empty_sheaf(), alongside
> SLAB_KMALLOC, if we go with the NO_RECURSE option.
Ack. without that hunk, CONFIG_MEM_ALLOC_PROFILING_DEBUG warns
"alloc_tag was not set" from __free_empty_sheaf().
Thanks for the review, respining v2.
--breno
prev parent reply other threads:[~2026-11-13 14:21 UTC|newest]
Thread overview: 5+ 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
2026-11-13 12:27 ` Catalin Marinas
2026-11-13 14:21 ` Breno Leitao [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=avcb-W5ZOWqI9SbN@gmail.com \
--to=leitao@debian.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=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.