[PATCH] reboot: use make_task_dead for the halt and power off fallback

Bradley Morgan posted 1 patch 1 week, 5 days ago
kernel/reboot.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
[PATCH] reboot: use make_task_dead for the halt and power off fallback
Posted by Bradley Morgan 1 week, 5 days ago
The reboot syscall calls do_exit(0) after kernel_halt() or
kernel_power_off().  Those are expected to stop the machine and not
return.  When they do return, the shutdown path has already disabled
interrupts and torn down state, and do_exit() then hits its
WARN_ON(irqs_disabled()).

That is an error path, not a clean exit.  Use make_task_dead() instead
of do_exit(0): it is built for this, fixes up the irqs disabled and
preempt state, and bounds repeated failure via oops_limit.  This
matches the make_task_dead pattern that exit.c already uses for the
oops path.

Splat from syzbot:

  ACPI: PM: Preparing to enter system sleep state S5
  kvm: exiting hardware virtualization
  reboot: Power down
  ------------[ cut here ]------------
  irqs_disabled()
  WARNING: kernel/exit.c:930 at do_exit+0x1cf7/0x2ae0 kernel/exit.c:930, CPU#0: init/6193
  Tainted: [L]=SOFTLOCKUP
  Call Trace:
   <TASK>
   __do_sys_reboot+0x36e/0x400 kernel/reboot.c:784
   do_syscall_64+0x115/0x840 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   </TASK>

Fixes: 001c28e57187 ("exit: Detect and fix irq disabled state in oops")
Reported-by: syzbot+8fdf0d8e10bdde1c2e88@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8fdf0d8e10bdde1c2e88
Cc: stable@vger.kernel.org
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
 kernel/reboot.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Changes since v1: v1 enabled IRQs and kept do_exit, fixing the
symptom.  Eric Biederman pointed out the real fix is to treat the
returned halt or power off as the error path it is, and call
make_task_dead instead.

diff --git a/kernel/reboot.c b/kernel/reboot.c
index bed6967bfa96..c10ac6a0200d 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -14,6 +14,7 @@
 #include <linux/kmod.h>
 #include <linux/kmsg_dump.h>
 #include <linux/reboot.h>
+#include <linux/sched/task.h>
 #include <linux/suspend.h>
 #include <linux/syscalls.h>
 #include <linux/syscore_ops.h>
@@ -777,11 +778,13 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
 
 	case LINUX_REBOOT_CMD_HALT:
 		kernel_halt();
-		do_exit(0);
+		/* machine_halt() was expected to not return. */
+		make_task_dead(SIGKILL);
 
 	case LINUX_REBOOT_CMD_POWER_OFF:
 		kernel_power_off();
-		do_exit(0);
+		/* machine_power_off() was expected to not return. */
+		make_task_dead(SIGKILL);
 		break;
 
 	case LINUX_REBOOT_CMD_RESTART2:
-- 
2.53.0
Re: [PATCH] reboot: use make_task_dead for the halt and power off fallback
Posted by Andrew Morton 1 week, 4 days ago
On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net> wrote:

> The reboot syscall calls do_exit(0) after kernel_halt() or
> kernel_power_off().  Those are expected to stop the machine and not
> return.  When they do return, the shutdown path has already disabled
> interrupts and torn down state, and do_exit() then hits its
> WARN_ON(irqs_disabled()).

Well...  why are they returning?  Is it both kernel_halt() and
kernel_power_off()?  The report seems to indicate that
kernel_power_off() is returning.

So is there a flaw in x86 machine_power_off() which we should be
addressing?

> That is an error path, not a clean exit.  Use make_task_dead() instead
> of do_exit(0): it is built for this, fixes up the irqs disabled and
> preempt state, and bounds repeated failure via oops_limit.  This
> matches the make_task_dead pattern that exit.c already uses for the
> oops path.

And make_tsk_dead() is __noreturn.
Re: [PATCH] reboot: use make_task_dead for the halt and power off fallback
Posted by Bradley Morgan 1 week, 4 days ago
On July 14, 2026 2:10:01 AM GMT+01:00, Andrew Morton
<akpm@linux-foundation.org> wrote:
>On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net>
>wrote:
>
>> The reboot syscall calls do_exit(0) after kernel_halt() or
>> kernel_power_off().  Those are expected to stop the machine and not
>> return.  When they do return, the shutdown path has already disabled
>> interrupts and torn down state, and do_exit() then hits its
>> WARN_ON(irqs_disabled()).
>
>Well...  why are they returning?  Is it both kernel_halt() and
>kernel_power_off()?  The report seems to indicate that
>kernel_power_off() is returning.

native_machine_power_off() has no __noreturn backstop.

(Only for kernel_power_off, kernel_halt() is theoretically safe, ends in
stop_this_cpu)

>So is there a flaw in x86 machine_power_off() which we should be
>addressing?

Well, yes, but it's really not that simple Andrew...

I did a quick dig at the other arches code and guess what? 

x86, arm, arm64, (loongarch, riscv)           power_off can all return,
(BUG!)


So just doing a fix arch specific isn't really right (unless we want a
3-5 patch series, which just adds more complication)

>> That is an error path, not a clean exit.  Use make_task_dead() instead
>> of do_exit(0): it is built for this, fixes up the irqs disabled and
>> preempt state, and bounds repeated failure via oops_limit.  This
>> matches the make_task_dead pattern that exit.c already uses for the
>> oops path.
>
>And make_tsk_dead() is __noreturn.

Nice catch! let's just remove break;, it's dead code

>
>

Thanks!
Re: [PATCH] reboot: use make_task_dead for the halt and power off fallback
Posted by Bradley Morgan 6 days, 8 hours ago
On July 14, 2026 4:48:09 PM GMT+01:00, Bradley Morgan <include@grrlz.net>
wrote:
>On July 14, 2026 2:10:01 AM GMT+01:00, Andrew Morton
><akpm@linux-foundation.org> wrote:
>>On Mon, 13 Jul 2026 06:23:32 +0000 Bradley Morgan <include@grrlz.net>
>>wrote:
>>
>>> The reboot syscall calls do_exit(0) after kernel_halt() or
>>> kernel_power_off().  Those are expected to stop the machine and not
>>> return.  When they do return, the shutdown path has already disabled
>>> interrupts and torn down state, and do_exit() then hits its
>>> WARN_ON(irqs_disabled()).
>>
>>Well...  why are they returning?  Is it both kernel_halt() and
>>kernel_power_off()?  The report seems to indicate that
>>kernel_power_off() is returning.
>
>native_machine_power_off() has no __noreturn backstop.
>
>(Only for kernel_power_off, kernel_halt() is theoretically safe, ends in
>stop_this_cpu)
>
>>So is there a flaw in x86 machine_power_off() which we should be
>>addressing?
>
>Well, yes, but it's really not that simple Andrew...
>
>I did a quick dig at the other arches code and guess what? 
>
>x86, arm, arm64, (loongarch, riscv)           power_off can all return,
>(BUG!)
>
>
>So just doing a fix arch specific isn't really right (unless we want a
>3-5 patch series, which just adds more complication)
>
>>> That is an error path, not a clean exit.  Use make_task_dead() instead
>>> of do_exit(0): it is built for this, fixes up the irqs disabled and
>>> preempt state, and bounds repeated failure via oops_limit.  This
>>> matches the make_task_dead pattern that exit.c already uses for the
>>> oops path.
>>
>>And make_tsk_dead() is __noreturn.
>
>Nice catch! let's just remove break;, it's dead code
>
>>
>>
>
>Thanks!


Andrew? What do you think of this? (Sorry for the ping)

Thanks!