tracing: wake up tasks reading trace_pipe on write to trace_marker

Currently we rely on other code periodically waking up trace reader. If there aren't any other data than markers, reader will never be woken up. Fix it.

Signed-off-by Marcin Slusarz <[email protected]>

Cc Steven Rostedt <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

---
 kernel/trace/trace.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

kernel/trace/trace.c +0 -0

index 086d363..02e04c8 100644

Quoted 17 lines · Marcin Slusarz

Currently we rely on other code periodically waking up trace reader. If there aren't any other data than markers, reader will never be woken up. Fix it.

Signed-off-by Marcin Slusarz <[email protected]>

Cc Steven Rostedt <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

---
 kernel/trace/trace.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

kernel/trace/trace.c +0 -0

index 086d363..02e04c8 100644

kernel/trace/trace.c int trace_array_vprintk(struct trace_array *tr, · line 1525

Quoted 6 lines

kernel/trace/trace.c +1 -0

@@ -1520,6 +1520,7 @@ int trace_array_vprintk(struct trace_array *tr,
 	if (!filter_check_discard(call, entry, buffer, event)) {
 		ring_buffer_unlock_commit(buffer, event);
 		ftrace_trace_stack(buffer, irq_flags, 6, pc);
+		trace_wake_up();
 	}
 

This can't work. trace_printk() and friends must be able to be used anywhere. This can cause race conditions with the rq locks in the scheduler.

But you do bring up a good idea. That is, perhaps we should have a way to attach to known safe tracepoints that we can hook to to check if a wake up should happen or not.

Quoted 7 lines

This can't work. trace_printk() and friends must be able to be used anywhere. This can cause race conditions with the rq locks in the scheduler.

But you do bring up a good idea. That is, perhaps we should have a way to attach to known safe tracepoints that we can hook to to check if a wake up should happen or not.

This could be a simple macro that takes the name of the trace event:

DEFINE_EVENT(event_tpl, event_name, ...);

TRACE_EVENT_NO_WAKE(event_name);

I think trace events should be wakeable by default as it looks safe for most of them. But probably we don't want that per event class.

In the unsafe list, I only have some sched and lock events in mind, but I bet there are some others.

Quoted 15 lines · Frederic Weisbecker

Quoted 7 lines

This can't work. trace_printk() and friends must be able to be used anywhere. This can cause race conditions with the rq locks in the scheduler.

But you do bring up a good idea. That is, perhaps we should have a way to attach to known safe tracepoints that we can hook to to check if a wake up should happen or not.

This could be a simple macro that takes the name of the trace event:

DEFINE_EVENT(event_tpl, event_name, ...);

Quoted 2 lines

TRACE_EVENT_NO_WAKE(event_name);

Yeah, that may be worth doing for 2.6.37. Might as well also add a trace_printk_nowake() too, when you know you are in dangerous locations like the scheduler or NMI.

Quoted 6 lines

I think trace events should be wakeable by default as it looks safe for most of them. But probably we don't want that per event class.

In the unsafe list, I only have some sched and lock events in mind, but I bet there are some others.

Yep, will put that on my todo list.

Thanks,