Messages in this thread | | | Date | Thu, 17 Nov 2022 21:17:26 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH] tracing/eprobe: Update cond flag before enabling trigger |
| |
On Wed, 16 Nov 2022 16:25:51 -0300 Rafael Mendonca <rafaelmendsr@gmail.com> wrote:
> That happens because enable_eprobe() will eventually trigger the > kmem/mm_page_alloc trace event: > > - enable_eprobe [trace_eprobe.c] > - trace_event_trigger_enable_disable [trace_events_trigger.c] > - trace_event_enable_disable [trace_events.c] > - __ftrace_event_enable_disable [trace_events.c] > - trace_buffered_event_enable [trace.c] > - alloc_pages_node [gfp.h] > ... > - __alloc_pages [page_alloc.c] > - trace_mm_page_alloc // eprobe event file without TRIGGER_COND bit set > > By the time kmem/mm_page_alloc trace event is hit, the eprobe event file > does not have the TRIGGER_COND flag set yet, which causes the eprobe's > trigger to be invoked (through the trace_trigger_soft_disabled() path) > without a trace record, causing a NULL pointer dereference when fetching > the event fields. > > Fix this by setting the cond flag beforehand when enabling the eprobe's > trigger. > > Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") > Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com> > ---
Thanks for the report, but I'm worried that this isn't enough because of how memory ordering can happen on different architectures. That is, just because you switch the order of updates, doesn't mean that the architecture will honor it.
I don't want to add memory barriers in the fast path, but instead we can simply check if rec is NULL in the handler.
So basically:
static void eprobe_trigger_func(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *rbe) { struct eprobe_data *edata = data->private_data;
if (!rec) return;
__eprobe_trace_func(edata, rec); }
And this should be documented.
-- Steve
| |