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

[Vlastimil Babka (SUSE)]

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!

>   slab_debug=UH,kmalloc-128
> 
> The series intentionally does not attempt to infer semantic ownership or
> identify the root cause of a use-after-free. It only preserves and prints
> additional track records that SLUB already knows how to collect.

Indeed, it would be generally impossible to infer I think.

> 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.

> - 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.

> Not included yet:
> 
> - KUnit coverage or a standalone reproducer

That would be nice.

> - object-size/order comparison data for representative caches

Could be useful too.

> - runtime benchmark data for slab_debug=U vs slab_debug=UH

This is probably not necessary as we do expect debugging has a performance
cost, and this is not doing anything extra slow, only copying the previous
tracking info? In practice the overhead depends on the workload anyway.

Thanks!

> Those should be added before a non-RFC submission if the direction looks
> acceptable.
> 
> Pengpeng Hou (5):
>   mm/slub: factor user tracking metadata size calculation
>   mm/slub: add optional previous lifetime user tracking
>   mm/slub: print previous object lifetime in debug reports
>   Documentation/mm: document SLUB previous lifetime tracking
>   mm/slub: sanitize previous lifetime tracking flags
> 
>  Documentation/admin-guide/mm/slab.rst |  22 ++++-
>  include/linux/slab.h                  |   3 +
>  mm/slab.h                             |   3 +-
>  mm/slub.c                             | 118 ++++++++++++++++++++++----
>  4 files changed, 128 insertions(+), 18 deletions(-)
>