linux-kernel - Re: [patch] fix emergency reboot: call reboot notifier list if possible

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Jan 2007 10:39:17 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: [patch] fix emergency reboot: call reboot notifier list if possible

* Russell King <rmk+lkml@....linux.org.uk> wrote:

> On Wed, Jan 17, 2007 at 10:13:19AM +0100, Ingo Molnar wrote:
> > we dont call the reboot notifiers during emergency reboot mainly because 
> > it could be called from atomic context and reboot notifiers are a 
> > blocking notifier list. But actually the kernel is often perfectly 
> > reschedulable in this stage, so we could as well process the 
> > reboot_notifier_list.
> 
> My experience has been that when there has been the need to use this
> facility, the kernel hasn't been reschedulable. [...]

this decision is totally automatic - so if your situation happens and 
the kernel isnt reschedulable, then the notifier chain wont be called 
and nothing changes from your perspective. Hm, perhaps this should be 
dependent on CONFIG_PREEMPT, to make sure preempt_count() is reliable?

but from my perspective this patch fixes a real regression.

updated patch attached below.

	Ingo

-------------------->
Subject: [patch] call reboot notifier list when doing an emergency reboot
From: Ingo Molnar <mingo@...e.hu>

my laptop does not reboot unless the shutdown notifiers are called
first. So the following command, which i use as a fast way to reboot
into a new kernel:

 echo b > /proc/sysrq-trigger

just hangs indefinitely after the kernel prints "System rebooting".

the thing is, that the kernel is actually reschedulable in this stage,
so we could as well process the reboot_notifier_list. (furthermore,
on -rt kernels this place is preemptable even during SysRq-b)

So just process the reboot notifier list if we are preemptable. This
will shut disk caches and chipsets off.

Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 kernel/sys.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

Index: linux/kernel/sys.c
===================================================================
--- linux.orig/kernel/sys.c
+++ linux/kernel/sys.c
@@ -29,6 +29,7 @@
 #include <linux/signal.h>
 #include <linux/cn_proc.h>
 #include <linux/getcpu.h>
+#include <linux/hardirq.h>

 #include <linux/compat.h>
 #include <linux/syscalls.h>
@@ -710,6 +711,15 @@ out_unlock:
  */
 void emergency_restart(void)
 {
+	/*
+	 * Call the notifier chain if we are not in an
+	 * atomic context:
+	 */
+#ifdef CONFIG_PREEMPT
+	if (!in_atomic() && !irqs_disabled())
+		blocking_notifier_call_chain(&reboot_notifier_list,
+					     SYS_RESTART, NULL);
+#endif
 	machine_emergency_restart();
 }
 EXPORT_SYMBOL_GPL(emergency_restart);
-
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/