linux-kernel - Re: [PATCH v1] kernel/reboot: Change registration order of legacy power-off handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 6 Jun 2022 16:07:32 +0300
From:   Dmitry Osipenko <dmitry.osipenko@...labora.com>
To:     Michael Ellerman <mpe@...erman.id.au>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v1] kernel/reboot: Change registration order of legacy
 power-off handler

On 6/6/22 16:06, Michael Ellerman wrote:
> Dmitry Osipenko <dmitry.osipenko@...labora.com> writes:
>> Hi Michael,
>>
>> On 6/5/22 05:01, Michael Ellerman wrote:
>>> Dmitry Osipenko <dmitry.osipenko@...labora.com> writes:
>>>> We're unconditionally registering sys-off handler for the legacy
>>>> pm_power_off() callback, this causes problem for platforms that don't
>>>> use power-off handlers at all and should be halted. Now reboot syscall
>>>> assumes that there is a power-off handler installed and tries to power
>>>> off system instead of halting it.
>>>>
>>>> To fix the trouble, move the handler's registration to the reboot syscall
>>>> and check the pm_power_off() presence.
>>>
>>> I'm seeing a qemu virtual machine (ppce500) fail to power off using the
>>> gpio-poweroff driver. I bisected it to this commit.
>>>
>>> I think the problem is that the machine is going via kernel_power_off(),
>>> not sys_reboot(), and so legacy_pm_power_off() has not been registered.
>>>
>>> If I just put the core_initcall back then it works as before. Not sure
>>> if that's a safe change in general though.
>>
>> Thank you very much for the testing and reporting the problem! I see now the two more cases that were missed previously:
>>
>> 1. There is the orderly_poweroff() used by some drivers.
>> 2. PowerPC may invoke do_kernel_power_off() directly from xmon code.
>>
>> Could you please test this change:
> 
> That works, thanks.
> 
> I tested both sysrq-o and the xmon power off path.
> 
> I couldn't come up with an easy way to test the orderly_poweroff()
> path, but it boils down to basically the same code in the end.
> 
> Tested-by: Michael Ellerman <mpe@...erman.id.au>
> 
> cheers

Awesome, thank you!

-- 
Best regards,
Dmitry