[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140626214901.596791200@goodmis.org>
Date: Thu, 26 Jun 2014 17:49:01 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Kosina <jkosina@...e.cz>, Michal Hocko <mhocko@...e.cz>,
Jan Kara <jack@...e.cz>,
Frederic Weisbecker <fweisbec@...il.com>,
Dave Anderson <anderson@...hat.com>,
Petr Mladek <pmladek@...e.cz>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Konstantin Khlebnikov <koct9i@...il.com>
Subject: [RFC][PATCH 0/5 v2] x86/nmi: Print all cpu stacks from NMI safely
This is version 2:
This is my proposal to print the NMI stack traces from an RCU stall safely.
Here's the gist of it.
Patch 1: add trace_seq_buffer_ptr() helper function to clean up
open coded trace_seq code. This is already in my 3.17 queue.
Patch 2: Add a new layer to trace_seq called seq_buf, that the trace
seq uses. The seq_buf is more generic, and does not supply its own
buffer. The buffer must be supplied when initializing the seq_buf.
Note, this patch too may be going into 3.17. There's some places in
the tracing code that I wanted to use a different size buffer
but still needed trace_seq to have a pre-allocated buffer. Having
this new layer will help me out. I have not added this to 3.17 until
I decide to make use of it.
Patch 3: move the seq_buf out of the tracing code. It's useful for other
purposes too. Like writing from an NMI context.
Patch 4: Add a per_cpu "printk_func" that printk calls. By default it calls
vprintk_def() which does what it has always done. This allows us to
override what printk() calls normally on a per cpu basis.
Patch 5: Have the NMI handler that dumps the stack trace just change the
printk_func to call a NMI safe printk function that writes to a per cpu
seq_buf. When all NMI handlers chimed in, the original caller prints
out the seq_buf buffers for each CPU from a printk safe context.
This is much less intrusive than the other versions out there.
Changes since V1:
- Note, I based this off of my 3.17 queue that already updated trace_seq
with a lot of comments from Andrew Morton. His comments have already
been incorporated into the trace_seq.c file. This patch set is on top
of those.
- Added a change that is in my 3.17 queue that cleans up open coded
calculations of the trace_seq buffer to get the current location of
the buffer.
- Biggest change is the added seq_buf. I'm keeping trace_seq doing the
stop everything once it fills up. But seq_buf will act more like other
utilities, as it will return what I would have written, and fills
up the buffer as much as it can. It sets an overflow flag to test to
see if there wasn't enough buffer space.
- I updated the last patch to use the seq_buf instead of the trace_seq
by using its own struct nmi_seq_buf that allocates the buffer used.
I also made some updates from previous reviews like not stripping the
log level from the NMI printks and just using it in the final output
as well as adding more comments and fixing the "return true" on a void
function.
Thoughts?
Steven Rostedt (Red Hat) (5):
tracing: Add trace_seq_buffer_ptr() helper function
tracing: Create seq_buf layer in trace_seq
seq_buf: Move the seq_buf code to lib/
printk: Add per_cpu printk func to allow printk to be diverted
x86/nmi: Perform a safe NMI stack trace on all CPUs
----
arch/x86/kernel/apic/hw_nmi.c | 84 ++++++++-
arch/x86/kvm/mmutrace.h | 2 +-
drivers/scsi/scsi_trace.c | 16 +-
include/linux/percpu.h | 3 +
include/linux/printk.h | 2 +
include/linux/seq_buf.h | 58 ++++++
include/linux/trace_seq.h | 23 ++-
kernel/printk/printk.c | 38 +++-
kernel/trace/Makefile | 1 +
kernel/trace/trace.c | 39 ++--
kernel/trace/trace_events.c | 6 +-
kernel/trace/trace_functions_graph.c | 6 +-
kernel/trace/trace_output.c | 14 +-
kernel/trace/trace_seq.c | 184 +++++++++---------
lib/Makefile | 2 +-
lib/seq_buf.c | 348 +++++++++++++++++++++++++++++++++++
lib/trace_seq.c | 303 ++++++++++++++++++++++++++++++
17 files changed, 976 insertions(+), 153 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists