tracing: Allow trace_printk() to nest in other tracing code
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Thu, 16 Jan 2020 13:20:18 +0000 (08:20 -0500)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Thu, 16 Jan 2020 13:20:18 +0000 (08:20 -0500)
commit82d1b8158c9a77c2c9b04c4af22fd62f3686cd9d
treefebd67ec6524f1d5eddf5cfa38dcf020b4f84b4f
parentcfc585a401764f0d352602d614c19866bb84738a
tracing: Allow trace_printk() to nest in other tracing code

trace_printk() is used to debug the kernel which includes the tracing
infrastructure. But because it writes to the ring buffer, and so does much
of the tracing infrastructure, the ring buffer's recursive detection will
drop writes to the ring buffer that is in the same context as the current
write is happening (it allows interrupts to write when normal context is
writing, but wont let normal context write while normal context is writing).

This can cause confusion and think that the code is where the trace_printk()
exists is not hit. To solve this, up the recursive nesting of the ring
buffer when trace_printk() is called before it writes to the buffer itself.

Note, this does make it dangerous to use trace_printk() in the ring buffer
code itself, because this basically disables the recursion protection of
trace_printk() buffer writes. But as trace_printk() is only used for
debugging, and if this does occur, the developer will see the cause real
quick (recursive blowing up of the stack). Thus the developer can deal with
that. But having trace_printk() silently ignored is a much bigger problem,
and disabling recursive protection is a small price to pay to fix it.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
kernel/trace/trace.c