Re: [patch 014/173] mm, tracing: record slab name for kmem_cache_free()

On 2/26/21 1:57 AM, Steven Rostedt wrote:

On Thu, 25 Feb 2021 09:49:15 -0800
Linus Torvalds [off-list ref] wrote:

quoted

On Thu, Feb 25, 2021 at 6:31 AM Steven Rostedt [off-list ref] wrote:

quoted

Here's nothing special about %s in TP_printk. It uses the same code as
printk() and what other string formatters use.

What is special is that the print is on data that is stored from a previous
time.

Well, technically that's not actually limited to just %s, although
that's the common case.

All our magic "%p*" formats do the same thing: they print out not the
argument _value_, but something that the pointer value points to.

So "%pD" takes a "struct file *" pointer, and follows it to the
dentry, and then from the dentry to the name. So it will in fact
follow pointers even more than "%s" does.

Correct, as I've told people about that as well.

I was thinking about this yesterday.

Freeing a slab name generally means removing a kernel module.
See the callers of kmem_cache_destroy.

We need to fix some of the trace events that call TP_printk with %pS
to get a symbol of a kernel module that maybe removed later.

quoted

It might indeed be worth having a warning for TP_printk() about any of
the formats that follow a pointer, exactly because of the whole "by
the time it actually prints, the pointer may be long gone".

Just a comment? Or should we add some check that gives a warning for when
one of these are used? That can be done at boot up or module load. (note, %s
can be OK for some cases, as mentioned in a previous email).

-- Steve