commit 587b9bfe0668 ("kernel/reboot: Use static handler for
register_platform_power_off()") addded a statically-allocated handler
so register_sys_off_handler() could be called before the slab allocator
is available.
That behavior was limited to the SYS_OFF_PRIO_PLATFORM priority.
However, it is also required for handlers such as PSCI on ARM and SBI on
RISC-V, which should be registered at SYS_OFF_PRIO_FIRMWARE. Currently,
this call stack crashes:
start_kernel()
setup_arch()
psci_dt_init()
psci_0_2_init()
register_sys_off_handler()
kmem_cache_alloc()
Generalize the code to use the statically-allocated handler for the
first registration, regardless of priority. Check .sys_off_cb for
conflicts instead of .cb_data; some callbacks (e.g. firmware drivers)
do not need any per-instance data, so .cb_data could be NULL.
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
---
kernel/reboot.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 3bba88c7ffc6..38c18d4f0a36 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -327,7 +327,7 @@ static int sys_off_notify(struct notifier_block *nb,
return handler->sys_off_cb(&data);
}
-static struct sys_off_handler platform_sys_off_handler;
+static struct sys_off_handler early_sys_off_handler;
static struct sys_off_handler *alloc_sys_off_handler(int priority)
{
@@ -338,10 +338,8 @@ static struct sys_off_handler *alloc_sys_off_handler(int priority)
* Platforms like m68k can't allocate sys_off handler dynamically
* at the early boot time because memory allocator isn't available yet.
*/
- if (priority == SYS_OFF_PRIO_PLATFORM) {
- handler = &platform_sys_off_handler;
- if (handler->cb_data)
- return ERR_PTR(-EBUSY);
+ if (!early_sys_off_handler.sys_off_cb) {
+ handler = &early_sys_off_handler;
} else {
if (system_state > SYSTEM_RUNNING)
flags = GFP_ATOMIC;
@@ -358,7 +356,7 @@ static struct sys_off_handler *alloc_sys_off_handler(int priority)
static void free_sys_off_handler(struct sys_off_handler *handler)
{
- if (handler == &platform_sys_off_handler)
+ if (handler == &early_sys_off_handler)
memset(handler, 0, sizeof(*handler));
else
kfree(handler);
--
2.37.4On Wed, 28 Dec 2022 08:19:13 PST (-0800), samuel@sholland.org wrote:
> commit 587b9bfe0668 ("kernel/reboot: Use static handler for
> register_platform_power_off()") addded a statically-allocated handler
> so register_sys_off_handler() could be called before the slab allocator
> is available.
>
> That behavior was limited to the SYS_OFF_PRIO_PLATFORM priority.
> However, it is also required for handlers such as PSCI on ARM and SBI on
> RISC-V, which should be registered at SYS_OFF_PRIO_FIRMWARE. Currently,
> this call stack crashes:
>
> start_kernel()
> setup_arch()
> psci_dt_init()
> psci_0_2_init()
> register_sys_off_handler()
> kmem_cache_alloc()
>
> Generalize the code to use the statically-allocated handler for the
> first registration, regardless of priority. Check .sys_off_cb for
> conflicts instead of .cb_data; some callbacks (e.g. firmware drivers)
> do not need any per-instance data, so .cb_data could be NULL.
>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
> kernel/reboot.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index 3bba88c7ffc6..38c18d4f0a36 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -327,7 +327,7 @@ static int sys_off_notify(struct notifier_block *nb,
> return handler->sys_off_cb(&data);
> }
>
> -static struct sys_off_handler platform_sys_off_handler;
> +static struct sys_off_handler early_sys_off_handler;
>
> static struct sys_off_handler *alloc_sys_off_handler(int priority)
> {
> @@ -338,10 +338,8 @@ static struct sys_off_handler *alloc_sys_off_handler(int priority)
> * Platforms like m68k can't allocate sys_off handler dynamically
> * at the early boot time because memory allocator isn't available yet.
> */
> - if (priority == SYS_OFF_PRIO_PLATFORM) {
> - handler = &platform_sys_off_handler;
> - if (handler->cb_data)
> - return ERR_PTR(-EBUSY);
> + if (!early_sys_off_handler.sys_off_cb) {
> + handler = &early_sys_off_handler;
> } else {
> if (system_state > SYSTEM_RUNNING)
> flags = GFP_ATOMIC;
> @@ -358,7 +356,7 @@ static struct sys_off_handler *alloc_sys_off_handler(int priority)
>
> static void free_sys_off_handler(struct sys_off_handler *handler)
> {
> - if (handler == &platform_sys_off_handler)
> + if (handler == &early_sys_off_handler)
> memset(handler, 0, sizeof(*handler));
> else
> kfree(handler);
Sorry for being slow here, I'd been assuming someone would Ack this but
it looks like maybe there's nobody in the maintainers file for
kernel/reboot.c? I'm fine taking this via the RISC-V tree if that's OK
with people, but the cover letter suggests the patch is necessary for
multiple patch sets.
On 2/14/23 18:17, Palmer Dabbelt wrote:
> On Wed, 28 Dec 2022 08:19:13 PST (-0800), samuel@sholland.org wrote:
>> commit 587b9bfe0668 ("kernel/reboot: Use static handler for
>> register_platform_power_off()") addded a statically-allocated handler
>> so register_sys_off_handler() could be called before the slab allocator
>> is available.
>>
>> That behavior was limited to the SYS_OFF_PRIO_PLATFORM priority.
>> However, it is also required for handlers such as PSCI on ARM and SBI on
>> RISC-V, which should be registered at SYS_OFF_PRIO_FIRMWARE. Currently,
>> this call stack crashes:
>>
>> start_kernel()
>> setup_arch()
>> psci_dt_init()
>> psci_0_2_init()
>> register_sys_off_handler()
>> kmem_cache_alloc()
>>
>> Generalize the code to use the statically-allocated handler for the
>> first registration, regardless of priority. Check .sys_off_cb for
>> conflicts instead of .cb_data; some callbacks (e.g. firmware drivers)
>> do not need any per-instance data, so .cb_data could be NULL.
>>
>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>> ---
>>
>> kernel/reboot.c | 10 ++++------
>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/reboot.c b/kernel/reboot.c
>> index 3bba88c7ffc6..38c18d4f0a36 100644
>> --- a/kernel/reboot.c
>> +++ b/kernel/reboot.c
>> @@ -327,7 +327,7 @@ static int sys_off_notify(struct notifier_block *nb,
>> return handler->sys_off_cb(&data);
>> }
>>
>> -static struct sys_off_handler platform_sys_off_handler;
>> +static struct sys_off_handler early_sys_off_handler;
>>
>> static struct sys_off_handler *alloc_sys_off_handler(int priority)
>> {
>> @@ -338,10 +338,8 @@ static struct sys_off_handler
>> *alloc_sys_off_handler(int priority)
>> * Platforms like m68k can't allocate sys_off handler dynamically
>> * at the early boot time because memory allocator isn't
>> available yet.
>> */
>> - if (priority == SYS_OFF_PRIO_PLATFORM) {
>> - handler = &platform_sys_off_handler;
>> - if (handler->cb_data)
>> - return ERR_PTR(-EBUSY);
>> + if (!early_sys_off_handler.sys_off_cb) {
>> + handler = &early_sys_off_handler;
>> } else {
>> if (system_state > SYSTEM_RUNNING)
>> flags = GFP_ATOMIC;
>> @@ -358,7 +356,7 @@ static struct sys_off_handler
>> *alloc_sys_off_handler(int priority)
>>
>> static void free_sys_off_handler(struct sys_off_handler *handler)
>> {
>> - if (handler == &platform_sys_off_handler)
>> + if (handler == &early_sys_off_handler)
>> memset(handler, 0, sizeof(*handler));
>> else
>> kfree(handler);
>
> Sorry for being slow here, I'd been assuming someone would Ack this but
> it looks like maybe there's nobody in the maintainers file for
> kernel/reboot.c? I'm fine taking this via the RISC-V tree if that's OK
> with people, but the cover letter suggests the patch is necessary for
> multiple patch sets.
See also Dmitry's reply[0] to the PSCI thread. (Maybe I should have sent
both conversions as one series?)
I am happy with the patches going through any tree. The kernel/reboot.c
patch is exactly the same between the two series, so it should not hurt
if it gets merged twice. Though if you take this series through the
RISC-V tree, maybe you want to create a tag for it?
I am not sure exactly what needs to be done here; I am happy to do
anything that would assist getting both series merged for v6.3, to avoid
a regression with axp20x[1].
Regards,
Samuel
[0]:
https://lore.kernel.org/lkml/0a180849-ba1b-2a82-ab06-ed1b8155d5ca@collabora.com/
[1]:
https://lore.kernel.org/lkml/e38d29f5-cd3c-4a2b-b355-2bcfad00a24b@sholland.org/
On 2/19/23 02:20, Samuel Holland wrote: > On 2/14/23 18:17, Palmer Dabbelt wrote: ... >> Sorry for being slow here, I'd been assuming someone would Ack this but >> it looks like maybe there's nobody in the maintainers file for >> kernel/reboot.c? I'm fine taking this via the RISC-V tree if that's OK >> with people, but the cover letter suggests the patch is necessary for >> multiple patch sets. > > See also Dmitry's reply[0] to the PSCI thread. (Maybe I should have sent > both conversions as one series?) > > I am happy with the patches going through any tree. The kernel/reboot.c > patch is exactly the same between the two series, so it should not hurt > if it gets merged twice. Though if you take this series through the > RISC-V tree, maybe you want to create a tag for it? > > I am not sure exactly what needs to be done here; I am happy to do > anything that would assist getting both series merged for v6.3, to avoid > a regression with axp20x[1]. > > Regards, > Samuel > > [0]: > https://lore.kernel.org/lkml/0a180849-ba1b-2a82-ab06-ed1b8155d5ca@collabora.com/ > [1]: > https://lore.kernel.org/lkml/e38d29f5-cd3c-4a2b-b355-2bcfad00a24b@sholland.org/ The reboot.c changes should be acked/applied by Rafael. I noticed that you haven't CC'd the linux-pm ML, maybe that's why it hasn't got the attention. -- Best regards, Dmitry
On Sat, 18 Feb 2023 15:32:06 PST (-0800), dmitry.osipenko@collabora.com wrote: > On 2/19/23 02:20, Samuel Holland wrote: >> On 2/14/23 18:17, Palmer Dabbelt wrote: > ... >>> Sorry for being slow here, I'd been assuming someone would Ack this but >>> it looks like maybe there's nobody in the maintainers file for >>> kernel/reboot.c? I'm fine taking this via the RISC-V tree if that's OK >>> with people, but the cover letter suggests the patch is necessary for >>> multiple patch sets. >> >> See also Dmitry's reply[0] to the PSCI thread. (Maybe I should have sent >> both conversions as one series?) >> >> I am happy with the patches going through any tree. The kernel/reboot.c >> patch is exactly the same between the two series, so it should not hurt >> if it gets merged twice. Though if you take this series through the >> RISC-V tree, maybe you want to create a tag for it? >> >> I am not sure exactly what needs to be done here; I am happy to do >> anything that would assist getting both series merged for v6.3, to avoid >> a regression with axp20x[1]. >> >> Regards, >> Samuel >> >> [0]: >> https://lore.kernel.org/lkml/0a180849-ba1b-2a82-ab06-ed1b8155d5ca@collabora.com/ >> [1]: >> https://lore.kernel.org/lkml/e38d29f5-cd3c-4a2b-b355-2bcfad00a24b@sholland.org/ > > The reboot.c changes should be acked/applied by Rafael. > I noticed that you haven't CC'd the linux-pm ML, maybe that's why it > hasn't got the attention. OK, I'm adding them here. Not sure if we're ment to re-send it to the list, no rush on my end I'm just scrubbing through some old stuff on patchwork again.
© 2016 - 2026 Red Hat, Inc.