Re: [PATCH] tracing/ftrace: use preempt_enable_no_resched_notrace in ring_buffer_time_stamp()

["Frédéric Weisbecker" <fweisbec@gmail.com>]

2008/12/16 Ingo Molnar <mingo@elte.hu>:
>
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
>> Impact: prevent a trace recursion
>>
>> After some tests with function graph tracer under x86-32, I saw some recursions
>> caused by ring_buffer_time_stamp() that calls preempt_enable_no_notrace() which
>> calls preempt_schedule() which is traced itself.
>>
>> This patch re-enables preemption without rescheduling.
>>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
>> ---
>>  kernel/trace/ring_buffer.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> applied to tip/tracing/ftrace, thanks Frederic!
>
> Does this explain+fix the weird crashes/reboots you were seeing?
>
>        Ingo
>

No, actually the functions tracers are protected against recursion,
but rescheduling attempts
during all trace insertions (and moreover a call to
prepare_ftrace_return with cancelled insertion)
is a useless payload.

The hard reboots I've seen are related to x86-64 while
disabling/reenabling a CPU through /sys/device/system/cpu
No tracer was enabled at these times (the problem still remains with
latest updates on -tip for half an hour).

One other thing: I've seen these pointless calls to preempt_schedule
while testing the function graph tracer on
VirtualBox. Since it provides virtual serial lines, it was more easy
to debug than usual (I haven't any serial line
on my box).
The function graph tracer hangs on VirtualBox with a x86-32 -tip. It
seems that the tracing is too slow and so hrtimer_interrupt()
does an eternal loop, assuming that a new time update has to be done
(because too much time elapsed during th tracing) after each
iteration.
I'm not sure what to do...disabling tracing for hrtimers or....