| 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
| ||
|
Message-ID: <a41c323a-5d69-0ff1-d0da-38eb55e1e4db@collabora.com>
Date: Wed, 1 Jun 2022 00:24:49 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
Greg Ungerer <gerg@...ux-m68k.org>,
Joshua Thompson <funaho@...ai.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Sebastian Reichel <sre@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Greentime Hu <green.hu@...il.com>,
Vincent Chen <deanbo422@...il.com>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Santosh Shilimkar <ssantosh@...nel.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Pavel Machek <pavel@....cz>,
Lee Jones <lee.jones@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <linux@...ck-us.net>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Michał Mirosław <mirq-linux@...e.qmqm.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-csky@...r.kernel.org,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
Parisc List <linux-parisc@...r.kernel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux-sh list <linux-sh@...r.kernel.org>,
xen-devel@...ts.xenproject.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v8 16/27] m68k: Switch to new sys-off handler API
On 5/31/22 22:04, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Tue, May 10, 2022 at 1:34 AM Dmitry Osipenko
> <dmitry.osipenko@...labora.com> wrote:
>> Kernel now supports chained power-off handlers. Use
>> register_power_off_handler() that registers power-off handlers and
>> do_kernel_power_off() that invokes chained power-off handlers. Legacy
>> pm_power_off() will be removed once all drivers will be converted to
>> the new sys-off API.
>>
>> Normally arch code should adopt only the do_kernel_power_off() at first,
>> but m68k is a special case because it uses pm_power_off() "inside out",
>> i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing],
>> while it's machine_power_off() that should invoke the pm_power_off(), and
>> thus, we can't convert platforms to the new API separately. There are only
>> two platforms changed here, so it's not a big deal.
>>
>> Acked-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>> Reviewed-by: Michał Mirosław <mirq-linux@...e.qmqm.pl>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
>
> Thanks for your patch, which is now commit f0f7e5265b3b37b0
> ("m68k: Switch to new sys-off handler API") upstream.
>
>> --- a/arch/m68k/emu/natfeat.c
>> +++ b/arch/m68k/emu/natfeat.c
>> @@ -15,6 +15,7 @@
>> #include <linux/string.h>
>> #include <linux/kernel.h>
>> #include <linux/module.h>
>> +#include <linux/reboot.h>
>> #include <linux/io.h>
>> #include <asm/machdep.h>
>> #include <asm/natfeat.h>
>> @@ -90,5 +91,5 @@ void __init nf_init(void)
>> pr_info("NatFeats found (%s, %lu.%lu)\n", buf, version >> 16,
>> version & 0xffff);
>>
>> - mach_power_off = nf_poweroff;
>> + register_platform_power_off(nf_poweroff);
>
> Unfortunately nothing is registered, as this is called very early
> (from setup_arch(), before the memory allocator is available.
> Hence register_sys_off_handler() fails with -ENOMEM, and poweroff
> stops working.
>
> Possible solutions:
> - As at most one handler can be registered,
> register_platform_power_off() could use a static struct sys_off_handler
> instance,
> - Keep mach_power_off, and call register_platform_power_off() later.
>
> Anything else?
> Thanks!
>
>> --- a/arch/m68k/mac/config.c
>> +++ b/arch/m68k/mac/config.c
>> @@ -12,6 +12,7 @@
>>
>> #include <linux/errno.h>
>> #include <linux/module.h>
>> +#include <linux/reboot.h>
>> #include <linux/types.h>
>> #include <linux/mm.h>
>> #include <linux/tty.h>
>> @@ -140,7 +141,6 @@ void __init config_mac(void)
>> mach_hwclk = mac_hwclk;
>> mach_reset = mac_reset;
>> mach_halt = mac_poweroff;
>> - mach_power_off = mac_poweroff;
>> #if IS_ENABLED(CONFIG_INPUT_M68K_BEEP)
>> mach_beep = mac_mksound;
>> #endif
>> @@ -160,6 +160,8 @@ void __init config_mac(void)
>>
>> if (macintosh_config->ident == MAC_MODEL_IICI)
>> mach_l2_flush = via_l2_flush;
>> +
>> + register_platform_power_off(mac_poweroff);
>> }
>
> This must have the same problem.
The static variant should be better, IMO. I'm not sure whether other platforms won't face the same problem once they will start using register_platform_power_off(). I'll send the fix, thank you for the testing!
--- >8 ---
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a091145ee710..4fea05d387dc 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -315,6 +315,37 @@ 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 *alloc_sys_off_handler(int priority)
+{
+ struct sys_off_handler *handler;
+
+ /*
+ * Platforms like m68k can't allocate sys_off handler dynamically
+ * at the early boot time.
+ */
+ if (priority == SYS_OFF_PRIO_PLATFORM) {
+ handler = &platform_sys_off_handler;
+ if (handler->cb_data)
+ return ERR_PTR(-EBUSY);
+ } else {
+ handler = kzalloc(sizeof(*handler), GFP_KERNEL);
+ if (!handler)
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return handler;
+}
+
+static void free_sys_off_handler(struct sys_off_handler *handler)
+{
+ if (handler == &platform_sys_off_handler)
+ memset(handler, 0, sizeof(*handler));
+ else
+ kfree(handler);
+}
+
/**
* register_sys_off_handler - Register sys-off handler
* @mode: Sys-off mode
@@ -345,9 +376,9 @@ register_sys_off_handler(enum sys_off_mode mode,
struct sys_off_handler *handler;
int err;
- handler = kzalloc(sizeof(*handler), GFP_KERNEL);
- if (!handler)
- return ERR_PTR(-ENOMEM);
+ handler = alloc_sys_off_handler(priority);
+ if (IS_ERR(handler))
+ return handler;
switch (mode) {
case SYS_OFF_MODE_POWER_OFF_PREPARE:
@@ -364,7 +395,7 @@ register_sys_off_handler(enum sys_off_mode mode,
break;
default:
- kfree(handler);
+ free_sys_off_handler(handler);
return ERR_PTR(-EINVAL);
}
@@ -391,7 +422,7 @@ register_sys_off_handler(enum sys_off_mode mode,
}
if (err) {
- kfree(handler);
+ free_sys_off_handler(handler);
return ERR_PTR(err);
}
@@ -422,7 +453,7 @@ void unregister_sys_off_handler(struct sys_off_handler *handler)
/* sanity check, shall never happen */
WARN_ON(err);
- kfree(handler);
+ free_sys_off_handler(handler);
}
EXPORT_SYMBOL_GPL(unregister_sys_off_handler);
Powered by blists - more mailing lists