| Message ID | 20221228161915.13194-2-samuel@sholland.org (mailing list archive) |
|---|---|
| State | Needs ACK, archived |
| Delegated to: | Palmer Dabbelt |
| Headers | show |
| Series | riscv: sbi: Switch to the sys-off handler API | expand |
| Context | Check | Description |
|---|---|---|
| conchuod/patch_count | success | Link |
| conchuod/cover_letter | success | Series has a cover letter |
| conchuod/tree_selection | success | Guessed tree name to be for-next |
| conchuod/fixes_present | success | Fixes tag not required for -next series |
| conchuod/maintainers_pattern | success | MAINTAINERS pattern errors before the patch: 13 and now 13 |
| conchuod/verify_signedoff | success | Signed-off-by tag matches author and committer |
| conchuod/kdoc | success | Errors and warnings before: 2 this patch: 2 |
| conchuod/module_param | success | Was 0 now: 0 |
| conchuod/alphanumeric_selects | success | Out of order selects before the patch: 57 and now 57 |
| conchuod/build_rv32_defconfig | success | Build OK |
| conchuod/build_warn_rv64 | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/dtb_warn_rv64 | success | Errors and warnings before: 0 this patch: 0 |
| conchuod/header_inline | success | No static functions without inline keyword in header files |
| conchuod/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 28 lines checked |
| conchuod/source_inline | success | Was 0 now: 0 |
| conchuod/build_rv64_nommu_k210_defconfig | success | Build OK |
| conchuod/verify_fixes | success | No Fixes tag |
| conchuod/build_rv64_nommu_virt_defconfig | success | Build OK |
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.
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);
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(-)