diff options
author | Rik van Riel <riel@redhat.com> | 2014-06-06 21:38:13 (GMT) |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2014-06-06 23:08:17 (GMT) |
commit | 984d74a72076a12b400339973e8c98fd2fcd90e5 (patch) | |
tree | d36c81545c10dbfa1513b8392aa10478eac7d13e /mm/memcontrol.c | |
parent | 310bf8f74927d0b945cd3e11dc5cef961ec04fd1 (diff) | |
download | linux-984d74a72076a12b400339973e8c98fd2fcd90e5.tar.xz |
sysrq: rcu-ify __handle_sysrq
Echoing values into /proc/sysrq-trigger seems to be a popular way to get
information out of the kernel. However, dumping information about
thousands of processes, or hundreds of CPUs to serial console can result
in IRQs being blocked for minutes, resulting in various kinds of cascade
failures.
The most common failure is due to interrupts being blocked for a very
long time. This can lead to things like failed IO requests, and other
things the system cannot easily recover from.
This problem is easily fixable by making __handle_sysrq use RCU instead
of spin_lock_irqsave.
This leaves the warning that RCU grace periods have not elapsed for a
long time, but the system will come back from that automatically.
It also leaves sysrq-from-irq-context when the sysrq keys are pressed,
but that is probably desired since people want that to work in
situations where the system is already hosed.
The callers of register_sysrq_key and unregister_sysrq_key appear to be
capable of sleeping.
Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Madper Xie <cxie@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/memcontrol.c')
0 files changed, 0 insertions, 0 deletions