linux-kernel - [PATCH v2 00/17] [request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1432026542-123571-1-git-send-email-long.wanglong@huawei.com>
Date:	Tue, 19 May 2015 09:08:45 +0000
From:	Wang Long <long.wanglong@...wei.com>
To:	<rostedt@...dmis.org>, <jkosina@...e.cz>, <pmladek@...e.cz>,
	<gregkh@...uxfoundation.org>
CC:	<stable@...r.kernel.org>, <wanglong@...qinren.net>,
	<peifeiyue@...wei.com>, <linux-kernel@...r.kernel.org>,
	<paulmck@...ux.vnet.ibm.com>, <dzickus@...hat.com>,
	<x86@...nel.org>, <long.wanglong@...wei.com>,
	<morgan.wang@...wei.com>, <sasha.levin@...cle.com>
Subject: [PATCH v2 00/17] [request for stable 3.10 inclusion] x86/nmi: Print all cpu stacks from NMI safely

This is my backport patch series to Fix the problem(backport to 3.10):
"
When trigger_all_cpu_backtrace() is called on x86, it will trigger an
NMI on each CPU and call show_regs(). But this can lead to a hard lock
up if the NMI comes in on another printk().
"
The solution is described in commit "a9edc88093287183ac934be44f295f183b2c62dd":
when the NMI triggers, it switches the printk routine for that CPU to call 
a NMI safe printk function that records the printk in a per_cpu seq_buf 
descriptor. After all NMIs have finished recording its data, the trace_
seqs are printed in a safe context.

The solution use "switch printk routine" and "seq_buf" infrastructures, but the
3.10 stable have no both of them.

The patch 1-13 backport the "seq_buf" infrastructures. in detail, patch 1, 2
and 6 only backport "seq_buf" related code.

The patch 14-15 backport the "switch printk routine".

The patch 16-17 is the patch to print all cpu stacks from NMI safely

as discussed in https://lkml.org/lkml/2015/5/13/497, in 3.10 stable, this is 
the only way to solve the problem and the backport code is a bit more.

v1 -> v2:
 * fix the indent error.
 * rebase on 3.10.79

Any thoughts?


Sasha Levin (1):
  x86/nmi: Fix use of unallocated cpumask_var_t

Steven Rostedt (Red Hat) (16):
  tracing: Create seq_buf layer in trace_seq
  tracing: Convert seq_buf_path() to be like seq_path()
  tracing: Convert seq_buf fields to be like seq_file fields
  tracing: Add a seq_buf_clear() helper and clear len and readpos in
    init
  seq_buf: Create seq_buf_used() to find out how much was written
  tracing: Use trace_seq_used() and seq_buf_used() instead of len
  seq_buf: Add seq_buf_can_fit() helper function
  tracing: Have seq_buf use full buffer
  tracing: Add seq_buf_get_buf() and seq_buf_commit() helper functions
  seq-buf: Make seq_buf_bprintf() conditional on CONFIG_BINARY_PRINTF
  seq_buf: Move the seq_buf code to lib/
  seq_buf: Fix seq_buf_vprintf() truncation
  seq_buf: Fix seq_buf_bprintf() truncation
  printk: Add per_cpu printk func to allow printk to be diverted
  printk/percpu: Define printk_func when printk is not defined
  x86/nmi: Perform a safe NMI stack trace on all CPUs

 arch/x86/kernel/apic/hw_nmi.c |  86 +++++++++-
 include/linux/percpu.h        |   4 +
 include/linux/printk.h        |   2 +
 include/linux/seq_buf.h       | 136 ++++++++++++++++
 kernel/printk.c               |  41 +++--
 lib/Makefile                  |   2 +-
 lib/seq_buf.c                 | 359 ++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 617 insertions(+), 13 deletions(-)
 create mode 100644 include/linux/seq_buf.h
 create mode 100644 lib/seq_buf.c

-- 
1.8.3.4

--
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/