linux-kernel - Re: [PATCH v2] reboot: Backup orderly

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jan 2016 10:05:21 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Keerthy <j-keerthy@...com>
Cc:	linux-kernel@...r.kernel.org, edubezval@...il.com,
	grygorii.strashko@...com, nm@...com, linux-pm@...r.kernel.org,
	linux-omap@...r.kernel.org, joel@....id.au,
	akpm@...ux-foundation.org, linux-arm-kernel@...ts.infradead.org,
	peterz@...radead.org, dyoung@...hat.com, josh@...htriplett.org,
	mpe@...erman.id.au, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v2] reboot: Backup orderly_poweroff


* Keerthy <j-keerthy@...com> wrote:

> orderly_poweroff is triggered when a graceful shutdown
> of system is desired. This may be used in many critical states of the
> kernel such as when subsystems detects conditions such as critical
> temperature conditions. However, in certain conditions in system
> boot up sequences like those in the middle of driver probes being
> initiated, userspace will be unable to power off the system in a clean
> manner and leaves the system in a critical state. In cases like these,
> the /sbin/poweroff will return success (having forked off to attempt
> powering off the system. However, the system overall will fail to
> completely poweroff (since other modules will be probed) and the system
> is still functional with no userspace (since that would have shut itself
> off).
> 
> However, there is no clean way of detecting such failure of userspace
> powering off the system. In such scenarios, it is necessary for a backup
> workqueue to be able to force a shutdown of the system when orderly
> shutdown is not successful after a configurable time period.
> 
> Signed-off-by: Keerthy <j-keerthy@...com>
> Suggested-by: Eduardo Valentin <edubezval@...il.com> 
> Reported-by: Nishanth Menon <nm@...com>
> ---
> Links to previous discussion can be found here:
> 
> http://www.spinics.net/lists/linux-omap/msg124925.html
> 
> Boot tested on DRA7.
> 
> changes in v2:
> 
> 	* Changed #ifdef to #if CONFIG_SHUTDOWN_BACKUP_DELAY_MS
> 
>  arch/Kconfig    |  7 +++++++
>  kernel/reboot.c | 23 ++++++++++++++++++-----
>  2 files changed, 25 insertions(+), 5 deletions(-)
> 
> Index: linux/arch/Kconfig
> ===================================================================
> --- linux.orig/arch/Kconfig	2016-01-11 15:26:07.732173131 +0530
> +++ linux/arch/Kconfig	2016-01-11 15:26:07.728173205 +0530
> @@ -37,6 +37,18 @@
>  	def_bool y
>  	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI && !PPC64
>  
> +config SHUTDOWN_BACKUP_DELAY_MS
> +	int "Backup shutdown delay in milli-seconds"
> +	default 0
> +	help
> +	  The number of milliseconds to delay before backup workqueue
> +	  executes attempting to poweroff the system after the
> +	  orderly_poweroff function has failed to complete.
> +
> +	  If set to 0, the backup workqueue is not active. The value
> +	  should be conservatively configured based on userspace latencies
> +	  expected for a given system.

I don't really understand this. In what circumstances can a reboot fail?

I think that is what should be fixed: a reboot should never fail, instead of 
introducing some sort of fragile timeout based method.

Thanks,

	Ingo