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

[Bradley Morgan <include@grrlz.net>]

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!