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:	Thu, 10 Jul 2014 16:09:07 -0700
From:	Andrew Morton <>
To:	Guenter Roeck <>
	Wim Van Sebroeck <>,
	Catalin Marinas <>,
	Maxime Ripard <>,
	Will Deacon <>,
	Arnd Bergmann <>,
	Heiko Stuebner <>,
	Russell King <>,
	Jonas Jensen <>,
	Randy Dunlap <>,
	Steven Rostedt <>,
	Ingo Molnar <>,
	Dmitry Eremin-Solenikov <>,
	David Woodhouse <>,
	Tomasz Figa <>,,
Subject: Re: [PATCH v3 0/7] kernel: Add support for restart notifier call

On Tue,  8 Jul 2014 20:37:56 -0700 Guenter Roeck <> wrote:

> The existing mechanisms have a number of drawbacks. Typically only one scheme
> to restart the system is supported (at least if arm_pm_restart is used).
> At least in theory there can be mutliple means to restart the system, some of
> which may be less desirable (for example one mechanism may only reset the CPU,
> while another may reset the entire system).

So the callbacks need to be prioritized.

> Using arm_pm_restart can also be
> racy if the function pointer is set from a driver, as the driver may be in
> the process of being unloaded when arm_pm_restart is called.
> Using the reboot notifier is always racy, as it is unknown if and when
> other functions using the reboot notifier have completed execution
> by the time the watchdog fires.
> To solve the problem, introduce a system restart notifier. This notifier
> is expected to be called from the architecture specific machine_restart()
> function. Drivers providing system restart functionality (such as the watchdog
> drivers mentioned above) are expected to register with this notifier.

It's worth mentioning here that the notifier_block priority scheme is
used to address the problem which was identified in the previous

If this scheme is to be successful we will need to set in place some
protocol for specifying how the priorities are managed.  If someone
sits down and writes a new restart handler, how is that person to
decide how to prioritize it against other handlers, both present and

Also, looking at the patches, you don't appear to have actually *used*
the prioritization - everything is left at zero.  So we'll end up using
the most-recently-registered handler to restart the system.  The
patches don't actually solve the problem which was identified in the
above paragraph?
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