Re: [PATCH] Add a slab corruption tracepoint

[Vlastimil Babka <vbabka@suse.cz>]

On 8/19/19 11:03 AM, David Howells wrote:
> Vlastimil Babka <vbabka@suse.cz> wrote:
> 
>> Shouldn't that include SLUB?
> 
> I've been using SLAB.  Looking in SLUB it's much less obvious where to insert
> the tracepoint.  check_bytes_and_report() maybe?

Perhaps object_err() and slab_err().

>> I'm surprised to see SLAB used for debugging refcounting these days,
> 
> The refcount debugging in question is not in SLAB, but rather in rxrpc; it's
> just SLAB detected the resulting memory corruption.

I understand, and it's what I meant - SLUB is better suited to debug
wrong uses (use-after-free, double free) that may be e.g. result of a
refcounting bug. You can configure it to perform the extra checks only
on the single cache you care about, and when it detects inconsistency it
will also print stacktraces of who last allocated and freed the object.

> rxrpc has tracepoints
> that track the refcounting, but SLAB printks a message to indicate the
> corruption and it's a bit tricky to work out where the printk happened with
> respect to the trace.

Could you correlate by timestamps?

>> as the SLUB debugging features are vastly superior, while SLAB ones are
>> being sometimes found to be broken for years and removed.
> 
> If SLUB is better than SLAB, shouldn't SLAB be removed?

It has been proposed before, but SLAB still has its users, who don't
care about the debugging scenarios that much.

> David
>