Skip to contentSkip to conversation

2.4 and 2.5: remove Alt-Sysrq-L

PATCH In review Russell King 2 participants 6 messages Mar 15, 2002 Char and misc drivers

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 2.4 and 2.5: remove Alt-Sysrq-L

Linus, Marcelo, Dave,

The following patch removes Alt-Sysrq-L and its associated hack to kill of PID1, the init process. This is a mis-feature.

If PID1 is killed, the kernel immediately enters an infinite loop in the depths of do_exit() with interrupts disabled, completely locking the machine. Obviously you can only reach for the reset button or power switch after this, leaving you with dirty filesystems.

This patch has appeared on LKML a couple of months ago.

drivers/char/sysrq.c +7 -22
@@ -284,24 +284,20 @@
 
 /* signal sysrq helper function
  * Sends a signal to all user processes */
-static void send_sig_all(int sig, int even_init)
+static void send_sig_all(int sig)
 {
 	struct task_struct *p;
 
 	for_each_task(p) {
-		if (p->mm) { /* Not swapper nor kernel thread */
-			if (p->pid == 1 && even_init)
-				/* Ugly hack to kill init */
-				p->pid = 0x8000;
-			if (p->pid != 1)
-				force_sig(sig, p);
-		}
+		if (p->mm && p->pid != 1)
+			/* Not swapper, init nor kernel thread */
+			force_sig(sig, p);
 	}
 }
 
 static void sysrq_handle_term(int key, struct pt_regs *pt_regs,
 		struct kbd_struct *kbd, struct tty_struct *tty) {
-	send_sig_all(SIGTERM, 0);
+	send_sig_all(SIGTERM);
 	console_loglevel = 8;
 }
 static struct sysrq_key_op sysrq_term_op = {
@@ -312,7 +308,7 @@
 
 static void sysrq_handle_kill(int key, struct pt_regs *pt_regs,
 		struct kbd_struct *kbd, struct tty_struct *tty) {
-	send_sig_all(SIGKILL, 0);
+	send_sig_all(SIGKILL);
 	console_loglevel = 8;
 }
 static struct sysrq_key_op sysrq_kill_op = {
@@ -321,17 +317,6 @@
 	action_msg:	"Kill All Tasks",
 };
 
-static void sysrq_handle_killall(int key, struct pt_regs *pt_regs,
-		struct kbd_struct *kbd, struct tty_struct *tty) {
-	send_sig_all(SIGKILL, 1);
-	console_loglevel = 8;
-}
-static struct sysrq_key_op sysrq_killall_op = {
-	handler:	sysrq_handle_killall,
-	help_msg:	"killalL",
-	action_msg:	"Kill All Tasks (even init)",
-};
-
 /* END SIGNAL SYSRQ HANDLERS BLOCK */
 
 
@@ -366,7 +351,7 @@
 #else
 /* k */	NULL,
 #endif
-/* l */	&sysrq_killall_op,
+/* l */	NULL,
 /* m */	&sysrq_showmem_op,
 /* n */	NULL,
 /* o */	NULL, /* This will often be registered
Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#1 lore raw
Quoted 2 lines · [email protected] said:

The following patch removes Alt-Sysrq-L and its associated hack to
kill of PID1, the init process. This is a mis-feature.

This is not a mis-feature.

Quoted 4 lines

If PID1 is killed, the kernel immediately enters an infinite loop in the depths of do_exit() with interrupts disabled, completely locking the machine. Obviously you can only reach for the reset button or power switch after this, leaving you with dirty filesystems.

This is a mis-feature. Leaving you without even the facility to use SysRq any further is just insane.

--
dwmw2

#2 lore raw
In reply to Russell King
Quoted 6 lines · David Woodhouse
Quoted 2 lines · [email protected] said:

The following patch removes Alt-Sysrq-L and its associated hack to
kill of PID1, the init process. This is a mis-feature.

This is not a mis-feature.

Quoted 7 lines
Quoted 4 lines

If PID1 is killed, the kernel immediately enters an infinite loop in the depths of do_exit() with interrupts disabled, completely locking the machine. Obviously you can only reach for the reset button or power switch after this, leaving you with dirty filesystems.

This is a mis-feature. Leaving you without even the facility to use SysRq any further is just insane.

Well, I've tried this approach, Linus rejected it.

If you'd like to take up this problem, be my guest.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#3 lore raw
Quoted 2 lines · [email protected] said:

Well, I've tried this approach, Linus rejected it.
If you'd like to take up this problem, be my guest.

Not really - I also tried already. But I'm disinclined to offer band-aids for the brokenness.

--
dwmw2

#4 lore raw
In reply to Russell King
Quoted 6 lines · David Woodhouse
Quoted 2 lines · [email protected] said:

Well, I've tried this approach, Linus rejected it.
If you'd like to take up this problem, be my guest.

Not really - I also tried already. But I'm disinclined to offer band-aids for the brokenness.

I don't know of any Linux kernel that has ever been able to cope with PID1 dying. I certainly remember facing the PID1 dying causing lockup as far back as 1.3 kernels, and I even tried to fix it back then. The argument put forward for not fixing it is that PID1 should not exit. Period.

The point here is not that the kernel itself can't cope with PID1 exiting, but that the code _bypasses_ the protection put into the kernel against PID1 exiting.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#5 lore raw
Quoted 5 lines · [email protected] said:

I don't know of any Linux kernel that has ever been able to cope with
PID1 dying. I certainly remember facing the PID1 dying causing lockup as far back as 1.3 kernels, and I even tried to fix it back then. The argument put forward for not fixing it is that PID1 should not exit. Period.

I distinctly recall it working perfectly OK in around 2.1.50. I had boxen where /sbin/init was a shell script which would bring up the interfaces, enable routing, and exit.

--
dwmw2