[1/3] kernel/reboot: Use the static sys-off handler for any priority

  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(-)
  

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.
  

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.
  

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.