From: Harry Yoo <harry@kernel.org>
To: Pengpeng Hou <pengpeng@iscas.ac.cn>,
"Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Cc: Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
liam@infradead.org, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] mm/slub: preserve previous object lifetime
Date: Tue, 16 Jun 2026 13:15:21 +0900 [thread overview]
Message-ID: <94eaac52-30a9-4607-a9e9-b2401fe7224f@kernel.org> (raw)
In-Reply-To: <20260615061202.23715-1-pengpeng@iscas.ac.cn>
[-- Attachment #1.1: Type: text/plain, Size: 1667 bytes --]
On 6/15/26 3:12 PM, Pengpeng Hou wrote:
> Hi Vlastimil, Harry,
>
> Thanks for the feedback.
>
> I agree that the terminology in the RFC cover letter was not precise
> enough. The case I was trying to describe is a duplicate/stale free by a
> previous owner after the object has already been freed and then reused by
> another user. In that case, the current SLAB_STORE_USER records can show
> the current allocation and the later bad free/check, but the previous
> completed alloc/free lifetime that explains where the stale pointer came
> from has already been overwritten.
I was confused, but I see now, thanks for clarifying :)
> This is not intended to compete with KASAN or infer semantic ownership.
> KASAN is better when it can be used, but the motivation here is the lower
> barrier of enabling slub_debug for a specific cache on an existing kernel,
> especially in field debugging environments.
Makes sense.
> Based on your comments, I will rework the non-RFC version to fold this
> into the existing U tracking instead of adding a separate H option, unless
> there is a preference for keeping the extra history behind an explicit
> flag.
Ack.
> I will keep the scope to one previous completed lifetime and avoid a
> larger history table/ring for now.
Ack.
> I will also add a small reproducer or KUnit coverage showing the lost
> previous-lifetime case,
Ack.
> plus object-size/order comparison data for a few
> representative caches.
I think we don't care much about the size on debug caches.
Looking forward to seeing the next version, Pengpeng.
Thanks!
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-06-16 4:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 6:39 [RFC PATCH 0/5] mm/slub: preserve previous object lifetime Pengpeng Hou
2026-06-11 6:39 ` [RFC PATCH 1/5] mm/slub: factor user tracking metadata size calculation Pengpeng Hou
2026-06-11 6:39 ` [RFC PATCH 2/5] mm/slub: add optional previous lifetime user tracking Pengpeng Hou
2026-06-11 6:39 ` [RFC PATCH 3/5] mm/slub: print previous object lifetime in debug reports Pengpeng Hou
2026-06-11 6:39 ` [RFC PATCH 4/5] Documentation/mm: document SLUB previous lifetime tracking Pengpeng Hou
2026-06-11 6:39 ` [RFC PATCH 5/5] mm/slub: sanitize previous lifetime tracking flags Pengpeng Hou
2026-06-11 7:19 ` [RFC PATCH 0/5] mm/slub: preserve previous object lifetime Harry Yoo
2026-06-11 17:13 ` Vlastimil Babka (SUSE)
2026-06-13 5:42 ` Harry Yoo
2026-06-11 17:28 ` Vlastimil Babka (SUSE)
2026-06-13 6:01 ` Harry Yoo
2026-06-15 6:12 ` Pengpeng Hou
2026-06-16 4:15 ` Harry Yoo [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=94eaac52-30a9-4607-a9e9-b2401fe7224f@kernel.org \
--to=harry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=hao.li@linux.dev \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pengpeng@iscas.ac.cn \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox