Re: [PATCH v8 07/27] kernel/reboot: Add kernel_can_power_off()

Dmitry Osipenko
2022-05-24T13:41:40Z

On 5/24/22 16:14, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>> Add kernel_can_power_off() helper that replaces open-coded checks of
>> the global pm_power_off variable. This is a necessary step towards
>> supporting chained power-off handlers.
>>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> Thanks for your patch, which is now commit 0e2110d2e910e44c
> ("kernel/reboot: Add kernel_can_power_off()") in pm/linux-next.
>
> This causes the "poweroff" command (Debian nfsroot) to no longer
> cleanly halt the system on arm32 systems, but fail with a panic
> instead:
>
> -reboot: System halted
> +reboot: Power down
> +Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
> +CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted
> 5.18.0-rc7-shmobile-00007-g0e2110d2e910 #1274
> +Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> + unwind_backtrace from show_stack+0x10/0x14
> + show_stack from dump_stack_lvl+0x40/0x4c
> + dump_stack_lvl from panic+0xf4/0x330
> + panic from do_exit+0x1c8/0x8e4
> + do_exit from __do_sys_reboot+0x174/0x1fc
> + __do_sys_reboot from ret_fast_syscall+0x0/0x54
> +Exception stack(0xf0815fa8 to 0xf0815ff0)
> +5fa0: 004e6954 00000000 fee1dead 28121969 4321fedc f0d94600
> +5fc0: 004e6954 00000000 00000000 00000058 befa0c78 00000000 befa0c10 004e56f8
> +5fe0: 00000058 befa0b6c b6ec8d45 b6e4a746
> +---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x00000000 ]---
>
> On arm64, "poweroff" causes a clean "reboot: Power down" before/after.
>
> On both arm32 and arm64, the same handlers are registered:
> - SYS_OFF_MODE_POWER_OFF_PREPARE: legacy_pm_power_off_prepare
> - SYS_OFF_MODE_POWER_OFF: legacy_pm_power_off
>
> On both arm32 and arm64, legacy_pm_power_off_prepare() is called.
> On both arm32 and arm64, legacy_pm_power_off() does not seem to
> be called.
>
> On arm32, both pm_power_off_prepare and pm_power_off are NULL.
> On arm64, pm_power_off_prepare is NULL, and
> pm_power_off is psci_sys_poweroff.
>
> Do you have a clue?
> Thanks!

Thank you, Geert! I see the problem, the kernel_can_power_off() checks whether power-off handler is registered, but it's always registered because legacy_pm_power_off is registered unconditionally. So it causes trouble for platforms that don't have power-off handler installed at all. All platforms that I tested have a power-off handler, so now wonder that I didn't notice this before.

This change should fix the problem, please give it a try:

--- 8< ---

diff --git a/kernel/reboot.c b/kernel/reboot.c
index 0bdc64ecf4f6..2d55b8bdb444 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -569,22 +569,6 @@ static int legacy_pm_power_off(struct sys_off_data *data)
return NOTIFY_DONE;
}

-/*
- * Register sys-off handlers for legacy PM callbacks. This allows legacy
- * PM callbacks co-exist with the new sys-off API.
- *
- * TODO: Remove legacy handlers once all legacy PM users will be switched
- * to the sys-off based APIs.
- */
-static int __init legacy_pm_init(void)
-{
- register_sys_off_handler(SYS_OFF_MODE_POWER_OFF, SYS_OFF_PRIO_DEFAULT,
- legacy_pm_power_off, NULL);
-
- return 0;
-}
-core_initcall(legacy_pm_init);
-
static void do_kernel_power_off_prepare(void)
{
blocking_notifier_call_chain(&power_off_prep_handler_list, 0, NULL);
@@ -670,6 +654,18 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
if (ret)
return ret;

+ /*
+ * Register sys-off handler for the legacy PM callback. This allows
+ * legacy PM callbacks co-exist with the new sys-off API.
+ *
+ * TODO: Remove legacy handler once all legacy PM users will be
+ * switched to the sys-off based APIs.
+ */
+ if (pm_power_off)
+ register_sys_off_handler(SYS_OFF_MODE_POWER_OFF,
+ SYS_OFF_PRIO_DEFAULT,
+ legacy_pm_power_off, NULL);
+
/* Instead of trying to make the power_off code look like
* halt when pm_power_off is not set do it the easy way.
*/

--
Best regards,
Dmitry