Thread (197 messages) 197 messages, 8 authors, 2021-02-26

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

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2021-02-25 02:03:09
Also in: mm-commits

On Wed, 24 Feb 2021 17:51:46 -0800
Linus Torvalds [off-list ref] wrote:
On Wed, Feb 24, 2021 at 5:37 PM Steven Rostedt [off-list ref] wrote:
quoted
Please do not apply this patch as is, it is very buggy!  
Sadly, it's already there and pushed out.  I try to wait a few hours
(sometimes overnight) with Andrew's series before pushing things out
in order to catch comments like this, but this one came too late.
I try to look at patches like this for these very mistakes. I don't
seem to be Cc'd on the original patch, and this looks to be the first
time I've seen this patch. I should update my lkml filter to send me
any patches that touch include/trace/ code or has TRACE_EVENT in it,
and forward it to my inbox if I'm not already on the Cc.
I can obviously revert, but if the fix is the two-liner you outlined,
perhaps that is better? Mind sending it as a patch (or just putting it
in your tracing tree)? Or Jacob? A tested patch along the lines that
Steven outlined?
I'm done for the night, but if nobody does anything by tomorrow, I can
write up a quick fix in a few minutes. I prefer the original author to
do it, just so they get into the habit of understanding strings in
events.

But even though it's very buggy, it wont break anything unless people
really try to. The breakage would require enabling the event, then
doing something that would free a slab and its name, then reading the
trace file that has the events. In other words, the risk is low, but
something you don't want on a production system. I don't see this
breaking current mainline testing, so its not urgent to get fixed
immediately.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help