Re: [RFC PATCH 0/5] mm/slub: preserve previous object lifetime

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]



On 6/12/26 2:28 AM, Vlastimil Babka (SUSE) wrote:
> On 6/11/26 08:39, Pengpeng Hou wrote:
>> SLAB_STORE_USER currently stores one allocation track and one free track
>> for an object. This is useful, but it loses part of the previous lifetime
>> when the object is reused: the new allocation overwrites the allocation
>> track, and a later stale free can overwrite the free track.
>>
>> For free-after-reuse bugs, the report can therefore contain the victim
>> allocation and the stale free, while the earlier alloc/free pair that
>> explains where the stale pointer came from is no longer available.
>>
>> This RFC adds an opt-in SLUB debug option to keep one previous completed
>> object lifetime. The option is disabled by default, is not part of the
>> default debug flags, and only takes effect when user tracking is already
>> enabled:
> 
> Sounds useful!
> 
>> This is sent as RFC because the user-visible interface and the cost/benefit
>> tradeoff should be agreed on before this becomes a normal patch series.
>> In particular, feedback would be useful on:
>>
>> - whether a separate H option is preferable to extending U directly
> 
> I think before we converted U to stackdepot, the memory overhead of the
> stacks was higher than U+H with stackdepot. So I think it would be
> acceptable to extend directly. If a user is willing to pay the current U
> overhead to debug something in production, the addition of U+H shouldn't
> make it suddenly unacceptable.

Agreed on extending U directly rather than having a separate option.

>> - whether H should require U, as implemented here, or imply U
>> - whether the extra per-object metadata is useful enough for this debug path
> 
> One could think of scenarios where even longer object history would be
> needed to find the culprit. But adding one extra lifetime probably has the
> biggest impact.

Heh, I was actually wondering if it would make sense to have e.g.) a
hash table (per cache) where each bucket can store N "extra" lifetime
history of objects with the same key, with each element storing
stackdepot handles and the object address :P

-- 
Cheers,
Harry / Hyeonggon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]