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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 7 Oct 2014 08:51:05 -0700
From:	Guenter Roeck <>
To:	One Thousand Gnomes <>
Subject: Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain

On Tue, Oct 07, 2014 at 11:39:03AM +0100, One Thousand Gnomes wrote:
> On Mon,  6 Oct 2014 22:28:03 -0700
> Guenter Roeck <> wrote:
> > Various drivers implement architecture and/or device specific means to
> > remove power from the system.  For the most part, those drivers set the
> > global variable pm_power_off to point to a function within the driver.
> > 
> > This mechanism has a number of drawbacks.  Typically only one scheme
> > to remove power is supported (at least if pm_power_off is used).
> > At least in theory there can be multiple means remove power, some of
> > which may be less desirable. For example, some mechanisms may only
> > power off the CPU or the CPU card, while another may power off the
> > entire system.  Others may really just execute a restart sequence
> > or drop into the ROM monitor. Using pm_power_off can also be racy
> > if the function pointer is set from a driver built as module, as the
> > driver may be in the process of being unloaded when pm_power_off is
> > called. If there are multiple poweroff handlers in the system, removing
> > a module with such a handler may inadvertently reset the pointer to
> > pm_power_off to NULL, leaving the system with no means to remove power.
> > 
> > Introduce a system poweroff handler call chain to solve the described
> > problems.  This call chain is expected to be executed from the
> > architecture specific machine_power_off() function.  Drivers providing
> > system poweroff functionality are expected to register with this call chain.
> > By using the priority field in the notifier block, callers can control
> > poweroff handler execution sequence and thus ensure that the poweroff
> > handler with the optimal capabilities to remove power for a given system
> > is called first.
> Nice...
> register_poweroff_handler_simple isn't threadsafe. I'm not sure it
> matters as we should only have one attempt per platform to use it anyway.
Yes, I know. Agreed, it should not matter, but maybe it can be solved by
using raw notifiers and spinlocks for protection.

> have_kernel_poweroff() has a similar problem - the answer isn't always
> valid by the time the call returns.
This is an interesting one. Logically the answer can not be guaranteed to be
correct by the time it is evaluated in the calling code, no matter how much
protection I add around it. Not sure if there is anything I can or should do
about that.

> The actual poweroff logic is more of a problem - several of the Intel
> PMICs are on i2c bus, so are not going to be happy in an atomic context
> so I wonder if that is storing up problems for the future ?
Yes, Philippe brought that up as well. I think I may have to use raw
notifiers, and use spinlocks for protection. Would this work ?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists