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