All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH 0/3] printk/seq-buf/NMI: Revisit of safe NMI printing with seq_buf code
@ 2014-11-19  4:39 Steven Rostedt
  2014-11-19  4:39 ` [RFC][PATCH 1/3] seq_buf: Move the seq_buf code to lib/ Steven Rostedt
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Steven Rostedt @ 2014-11-19  4:39 UTC (permalink / raw)
  To: linux-kernel
  Cc: Linus Torvalds, Ingo Molnar, Andrew Morton, Jiri Kosina, Petr Mladek

Linus and Andrew,

You were the ones that brought up issues with this change, so I want
to get your thoughts on it after we worked quite a bit to clean things up.

Here's where it all started:

 Link: http://lkml.kernel.org/r/20140619213329.478113470@goodmis.org

Linus,

You had issues with moving trace_seq.c to lib/ mainly due to the name
as it stopped having anything to do with tracing.

To fix that, I created a seq_buf.c code and converted trace_seq.c to
use it. seq_buf.c is a bit more generic than trace_seq, which has some
things that are hard coded to tracing. I restructured the code to
follow seq_file.c. In fact, to test this, I have a patch that converts
seq_file.c to use the seq_buf.c code just like trace_seq.c does, and
that will remove the duplicate code that both files are doing now.

But consolidating seq_file.c with trace_seq.c is not the reason for this
patch set, although I plan on doing that if this patch set gets in.
The reason for this patch set is to remove the race of performing a
printk() from NMI context. What it does instead is, each CPU that does
an NMI stack dump (sysrq-l) writes to a per_cpu seq_buf instead of
writing with printk(). Then the caller of the NMI stack dumps performs
the printk() using the data written in the seq_buf buffers.

This also makes doing an NMI stack dump with sysrq-l less intrusive on
the system as all CPUs no longer have to wait for all other CPUs to
finish printing.

It also solves the problem of deadlocking the system if the NMI stack
trace happens on a CPU that is currently doing a printk.

Andrew,

I incorporated all your comments from last time and did even more.
I based the seq-buf code off of the seq_file code as I stated previously
and made it much more generic. Well, it works for seq_file just as well
as it works for trace_seq and the NMI printing code.

What are your thoughts on this? Can I go ahead and include this in
my queue for 3.19?

I have a bunch of changes to trace_seq queued already, but I left out 
the creation of seq_buf until I get an OK for these final patches. I don't
want to make a generic seq_buf if trace_seq is the only one that is
going to use it.


Then there's the other two patches as well.

The second patch creates a per_cpu function hook that allows one to override
what printk does. This lets me set the NMI handler to make printk temporarily
point to the seq_buf functions such that the dump_stack() code writes to
the seq_buf instead of doing the printk().

The third patch is what implements the NMI code to use seq_buf.

Let me know what you think.


Thanks!

-- Steve

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
rfc/seq-buf

Head SHA1: 948a6c8fbca4d96a8c4938ba28bd9c983df14eda


Steven Rostedt (Red Hat) (3):
      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 |  91 ++++++++++-
 include/linux/percpu.h        |   3 +
 include/linux/printk.h        |   2 +
 kernel/printk/printk.c        |  38 +++--
 kernel/trace/Makefile         |   1 -
 kernel/trace/seq_buf.c        | 359 ------------------------------------------
 lib/Makefile                  |   2 +-
 lib/seq_buf.c                 | 359 ++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 480 insertions(+), 375 deletions(-)

^ permalink raw reply	[flat|nested] 15+ messages in thread
* [RFC][PATCH 0/3] x86/nmi: Print all cpu stacks from NMI safely
@ 2014-06-19 21:33 Steven Rostedt
  2014-06-19 21:33 ` [RFC][PATCH 3/3] x86/nmi: Perform a safe NMI stack trace on all CPUs Steven Rostedt
  0 siblings, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2014-06-19 21:33 UTC (permalink / raw)
  To: linux-kernel
  Cc: Linus Torvalds, Ingo Molnar, Andrew Morton, Jiri Kosina,
	Michal Hocko, Jan Kara, Frederic Weisbecker, Dave Anderson,
	Petr Mladek

This is my proposal to print the NMI stack traces from an RCU stall safely.
Here's the gist of it.

Patch 1: move the trace_seq out of the tracing code. It's useful for other
 purposes too. Like writing from an NMI context.

Patch 2: 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 3: 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
 trace_seq. When all NMI handlers chimed in, the original caller prints
 out the trace_seqs for each CPU from a printk safe context.

This is much less intrusive than the other versions out there.

Note, The biggest change was the moving of trace_seq code out of trace_output.c
and into the new trace_seq.c library.

Thoughts?


Steven Rostedt (Red Hat) (3):
      trace_seq: Move the trace_seq 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 |  66 ++++++++-
 include/linux/percpu.h        |   3 +
 include/linux/printk.h        |   2 +
 include/linux/trace_seq.h     |  68 ++--------
 kernel/printk/printk.c        |  38 ++++--
 kernel/trace/trace.c          |  24 ----
 kernel/trace/trace_output.c   | 268 -------------------------------------
 kernel/trace/trace_output.h   |  16 ---
 lib/Makefile                  |   2 +-
 lib/trace_seq.c               | 303 ++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 412 insertions(+), 378 deletions(-)

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2014-11-19 13:03 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-19  4:39 [RFC][PATCH 0/3] printk/seq-buf/NMI: Revisit of safe NMI printing with seq_buf code Steven Rostedt
2014-11-19  4:39 ` [RFC][PATCH 1/3] seq_buf: Move the seq_buf code to lib/ Steven Rostedt
2014-11-19  5:04   ` Steven Rostedt
2014-11-19  4:39 ` [RFC][PATCH 2/3] printk: Add per_cpu printk func to allow printk to be diverted Steven Rostedt
2014-11-19  4:39 ` [RFC][PATCH 3/3] x86/nmi: Perform a safe NMI stack trace on all CPUs Steven Rostedt
2014-11-19 10:41   ` Borislav Petkov
2014-11-19 10:44     ` Jiri Kosina
2014-11-19 10:53       ` Borislav Petkov
2014-11-19 13:02     ` Petr Mladek
  -- strict thread matches above, loose matches on Subject: below --
2014-06-19 21:33 [RFC][PATCH 0/3] x86/nmi: Print all cpu stacks from NMI safely Steven Rostedt
2014-06-19 21:33 ` [RFC][PATCH 3/3] x86/nmi: Perform a safe NMI stack trace on all CPUs Steven Rostedt
2014-06-20 13:58   ` Don Zickus
2014-06-20 14:21     ` Steven Rostedt
2014-06-20 14:55   ` Petr Mládek
2014-06-20 15:17     ` Steven Rostedt
2014-06-23 16:12   ` Paul E. McKenney

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.