Linux Documentation
 help / color / mirror / Atom feed
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 --]

      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