From: Oleg Nesterov <oleg@redhat.com>
To: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
Cc: Christian Brauner <brauner@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
wsd_upstream@mediatek.com, bobule.chang@mediatek.com,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
chenqiwu <chenqiwu@xiaomi.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Breno Leitao <leitao@debian.org>,
Mateusz Guzik <mjguzik@gmail.com>
Subject: Re: [RFC PATCH] exit: Skip panic in do_exit() during poweroff
Date: Fri, 11 Apr 2025 16:06:02 +0200 [thread overview]
Message-ID: <20250411140601.GG5322@redhat.com> (raw)
In-Reply-To: <20250410210507.GD15280@redhat.com>
Add cc'es.
A similar problem was recently reported,
https://lore.kernel.org/all/20250403-exit-v1-1-8e9266bfc4b7@debian.org/
and I didn't realize this is another thread.
On 04/10, Oleg Nesterov wrote:
>
> Well...
>
> Let me repeat. I don't understand the kernel/reboot.c paths, you can
> safely ignore me.
>
> But I still think that you target the wrong goal. Quite possibly I am
> wrong.
>
> On 04/10, Tze-nan Wu wrote:
> >
> > If PID 1 exits due to the unreliable userspace after kernel_power_off()
> > invoked,
>
> Why. Why the global init does do_exit()? It should not, that is all.
> It doesn't matter if it is single threaded or not.
>
> As for sys_reboot(), I think that kernel_power_off() must be __noreturn,
> and sys_reboot() should use BUG() after LINUX_REBOOT_CMD_POWER_OFF/_HALT
> instead of do_exit().
>
> If nothing else. do_exit() also does debug_check_no_locks_held() and
> sys_reboot() calls do_exit() with system_transition_mutex held.
>
> IOW. IMO, it is not that do_exit() needs some changes. The very fact
> that the global init does do_exit() is wrong, this should be fixed.
>
> But again, again, I can't really comment.
>
> Oleg.
>
> > the panic follow by the last thread of global init exited in
> > do_exit() will stop the kernel_power_off() procedure, turn a shutdown
> > behavior into panic flow(reboot).
> >
> > Add a condition check to ensure that the panic triggered by the last
> > thread of the global init exiting, only occurs while:
> > ( system_state != SYSTEM_POWER_OFF and system_state != SYSTEM_RESTART).
> > Otherwise, WARN() instead.
> >
> > [On Android 16 with arm64 arch]
> > Here's a scenario where the global init exits during kernel_power_off:
> > If PID 1 encounters a page fault after kernel_power_off() has been
> > invoked, the kernel will fail to handle the page fault because the
> > disk(UFS) has already shut down.
> > Consequently, the kernel will send a SIGBUS to PID 1 to indicate the
> > page fault failure, and ultimately, the panic will occur after PID 1
> > exits due to receiving the SIGBUS.
> >
> > cpu1 cpu2
> > ---------- ----------
> > kernel_power_off() start
> > UFS shutdown
> > ... PID 1 page fault
> > ... page fault handle failure
> > ... PID 1 received SIGBUS
> > ... panic
> > kernel_power_off() not done
> >
> > Backtrace while PID 1 received signal 7:
> > init-1 [007] d..1 41239.922385: \
> > signal_generate: sig=7 errno=0 code=2 comm=init pid=1 grp=0 res=0
> > init-1 [007] d..1 41239.922389: kernel_stack: <stack trace>
> > => __send_signal_locked
> > => send_signal_locked
> > => force_sig_info_to_task
> > => force_sig_fault
> > => arm64_force_sig_fault
> > => do_page_fault
> > => do_translation_fault
> > => do_mem_abort
> > => el0_ia
> > => el0t_64_sync_handler
> >
> > Simplified kernel log:
> > kernel_power_off() invoked by pt_notify_thread.
> > [41239.526109] pt_notify_threa: reboot set flag, old value 0x********,
> > *.
> > [41239.526114] pt_notify_threa: reboot set flag new value 0x********.
> > UFS reject I/O after kerenl_power_off.
> > [41239.686411] scsi +scsi******** apexd: sd* ******** rejecting I/O to
> > offline device.
> > Lots of I/O error & erofs error happened after kernel_power_off().
> > [41239.690312] apexd: I/O error, dev sdc, sector ******* op ***:(READ)
> > flags 0x**** phys_seg ** prio class 0.
> > [41239.690465] apexd: I/O error, dev sdc, sector ******* op ***:(READ)
> > flags 0x**** phys_seg ** prio class 0.
> > ...
> > ...
> > [41239.922265] init: erofs: (device ****): z_erofs_read_folio: read
> > error * @ *** of nid ********.
> > [41239.922341] init: erofs: (device ****): z_erofs_read_folio: read
> > error * @ *** of nid ********.
> > Finally device panic due to PID 1 received SIGBUS.
> > [41239.923789] init: Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x00000007
> >
> > Fixes: 43cf75d96409 ("exit: panic before exit_mm() on global init exit")
> > Link: https://lore.kernel.org/all/20191219104223.xvk6ppfogoxrgmw6@wittgenstein/
> > Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
> > ---
> >
> > I am also wondering if this patch is reasonable?
> >
> > From my perspective, there are two reasons not to trigger such panic
> > during kernel_power_off() or kernel_restart():
> > 1. It is not worthwhile to interrupt kernel_power_off() by a panic
> > resulted from userspace instability.
> > 2. The panic in do_exit() was originally designed to ensure a usable
> > coredump if the last thread of the global init process exited.
> > However, capture a coredump triggered by userspace crash after
> > kernel_power_off() seems not particularly useful, in my opinion.
> >
> > In certain scenarios, a kernel module may need to directly power off
> > from kernel space to protect hardware (e.g., thermal protection).
> > In my opinion, rather than causing a panic during kernel_power_off(),
> > it sounds better to allow the device to complete its power-off process.
> >
> > Appreciate for any comment on this, if there's any better way to
> > handle this panic, please point me out.
> >
> > ---
> > kernel/exit.c | 14 ++++++++++----
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/exit.c b/kernel/exit.c
> > index 1dcddfe537ee..23cb6b42a1f1 100644
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -901,11 +901,17 @@ void __noreturn do_exit(long code)
> > if (group_dead) {
> > /*
> > * If the last thread of global init has exited, panic
> > - * immediately to get a useable coredump.
> > + * immediately to get a usable coredump, except when the
> > + * device is currently powering off or restarting.
> > */
> > - if (unlikely(is_global_init(tsk)))
> > - panic("Attempted to kill init! exitcode=0x%08x\n",
> > - tsk->signal->group_exit_code ?: (int)code);
> > + if (unlikely(is_global_init(tsk))) {
> > + if (system_state != SYSTEM_POWER_OFF &&
> > + system_state != SYSTEM_RESTART)
> > + panic("Attempted to kill init! exitcode=0x%08x\n",
> > + tsk->signal->group_exit_code ?: (int)code);
> > + WARN(1, "Attempted to kill init! exitcode=0x%08x\n",
> > + tsk->signal->group_exit_code ?: (int)code);
> > + }
> >
> > #ifdef CONFIG_POSIX_TIMERS
> > hrtimer_cancel(&tsk->signal->real_timer);
> > --
> > 2.45.2
> >
next prev parent reply other threads:[~2025-04-11 14:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 14:39 [RFC PATCH] exit: Skip panic in do_exit() during poweroff Tze-nan Wu
2025-04-10 21:05 ` Oleg Nesterov
2025-04-11 14:06 ` Oleg Nesterov [this message]
2025-04-14 13:02 ` Tze-nan Wu (吳澤南)
2025-04-14 16:50 ` Oleg Nesterov
2025-04-15 8:41 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250411140601.GG5322@redhat.com \
--to=oleg@redhat.com \
--cc=Tze-nan.Wu@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bobule.chang@mediatek.com \
--cc=brauner@kernel.org \
--cc=chenqiwu@xiaomi.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mjguzik@gmail.com \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.