On Wed, Jan 21, 2015 at 5:03 PM, Namhyung Kim [off-list ref] wrote:
AFAIK a trigger can be fired before allocating a ring buffer if it
doesn't use the event record (i.e. has filter) or ->post_trigger bit
set (stacktrace). Please see ftrace_trigger_soft_disabled().
yes, but such trigger has no arguments, so I would have to hack
ftrace_trigger_soft_disabled() to pass 'ctx' further down
and through all pointer dereferences and list walking.
Also there is no return value, so I have to add it as well
similar to post-triggers.
that's quite a bit of overhead that I would like to avoid.
Actually now I'm thinking to move condition
if (ftrace_file->flags & TRACE_EVENT_FL_BPF)
before ftrace_trigger_soft_disabled() check.
So programs always run first and if they return non-zero
then all standard processing will follow.
May be return value from the program can influence triggers.
That will nicely replace bpf_dump_stack()...the program
will return ETT_STACKTRACE constant to trigger dump.
This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
Probably historical before static_key was done.
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov [off-list ref] wrote:
quoted
This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
Probably historical before static_key was done.
No, it's not historical at all. The "soft-disable" is a way to enable
from any context. You can't enable a static key from NMI or interrupt
context, but you can enable a "soft-disable" there.
As you can enable or disable events from any function that the function
tracer may trace, I needed a way to enable them (make the tracepoint
active), but do nothing until something else turns them on.
-- Steve
On Wed, Jan 21, 2015 at 5:56 PM, Steven Rostedt [off-list ref] wrote:
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov [off-list ref] wrote:
quoted
quoted
This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
Probably historical before static_key was done.
No, it's not historical at all. The "soft-disable" is a way to enable
from any context. You can't enable a static key from NMI or interrupt
context, but you can enable a "soft-disable" there.
As you can enable or disable events from any function that the function
tracer may trace, I needed a way to enable them (make the tracepoint
active), but do nothing until something else turns them on.
Thanks for explanation. Makes sense.
Speaking of nmi... I think I will add a check that if (in_nmi())
just skip running the program, since supporting this use
case is not needed at the moment.