Thread (16 messages) flat view 16 messages, 5 authors, 2015-06-08

Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1)

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2015-05-19 03:27:12
Also in: lkml

On Mon, 2015-05-18 at 14:29 +0200, Jiri Kosina wrote:
yOn Sat, 16 May 2015, Torsten Duwe wrote:
quoted
quoted
quoted
There's got to be a better solution than this.
Can you think of a better approach?
Maybe a per thread variable to lock out a recursion into tracing?
Thanks for your doubt.
ftrace already handles recursion protection by itself (depending on the 
per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag).
OK, so I wonder why that's not working for us?
It's however not really well-defined what to do when recursion would 
happen. Therefore __notrace__ annotation, that just completely avoid such 
situation by making tracing impossible, looks like saner general solution 
to me.
I disagree. Correctly annotating all functions that might be called ever and
for all time is a maintenance nightmare and is never going to work in the long
term.

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