public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Machek <pavel@ucw.cz>
Cc: "Andrew Morton" <akpm@osdl.org>,
	linux-pm@osdl.org,
	"Martin MOKREJŠ" <mmokrejs@ribosome.natur.cuni.cz>,
	john@illhostit.com, sjordet@gmail.com, fastboot@lists.osdl.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Zlatko Calusic" <zlatko.calusic@iskon.hr>,
	"Linus Torvalds" <torvalds@osdl.org>,
	"José Luis Domingo López" <jdomingo@24x7linux.com>,
	ncunningham@cyclades.com, linux-kernel@24x7linux.com
Subject: FYI: device_suspend(...) in kernel_power_off().
Date: Sun, 07 Aug 2005 06:48:40 -0600	[thread overview]
Message-ID: <m13bplykt3.fsf_-_@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1123193791.9025.77.camel@localhost> (Nigel Cunningham's message of "Fri, 05 Aug 2005 08:16:31 +1000")

[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]


Early in the 2.6.13 process my kexec related patches were introduced
into the reboot path, and under the rule you touch it you fix it
it I have been involved in tracking quite a few regressions
on the reboot path.

Recently with Benjamin Herrenschmidt's removal of
device_suppend(PMSG_SUPPEND) from kernel_power_off(),
it seems the last of the issues went away.  I asked
for confirmation that reintroducing the patch below 
would break systems and I received it.

The experimental evidence then is that calling 
device_suspend(PMSG_SUSPEND) in kernel_power_off
when performing an acpi_power_off is actively harmful.

There as been a fair amount of consensus that calling
device_suspend(...) in the reboot path was inappropriate now, because
the device suspend code was too immature.   With this latest
piece of evidence it seems to me that introducing device_suspend(...)
in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec
can never be appropriate.  I am including as many people as
I can on this so we in our collective wisdom don't forget this
lesson.

What lead us to this situation was a real problem, and a desire
to fix it.  Currently linux has a proliferation of interfaces
to place devices in different states.  The reboot notifiers,
device_suspend(...), device_shutdown+system_state, remove_one,
module_exit, and probably a few I'm not aware of.  Each interface
introduced by a different author wanting to solve a different problem.
Just writing this list of interfaces is confusing.  The implementation
task for device driver writers appears even harder as simultaneously
implementing all of these interfaces correctly seems not to happen.

The lesson: fixing this problem is heavy lifting, and that
device_suspend() in the reboot path is not the answer.

Eric


This is the patch that subtly and mysterously broke things.
> diff --git a/kernel/sys.c b/kernel/sys.c
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -404,6 +404,7 @@ void kernel_halt(void)
>  {
>  	notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
>  	system_state = SYSTEM_HALT;
> +	device_suspend(PMSG_SUSPEND);
>  	device_shutdown();
>  	printk(KERN_EMERG "System halted.\n");
>  	machine_halt();
> @@ -414,6 +415,7 @@ void kernel_power_off(void)
>  {
>  	notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
>  	system_state = SYSTEM_POWER_OFF;
> +	device_suspend(PMSG_SUSPEND);
>  	device_shutdown();
>  	printk(KERN_EMERG "Power down.\n");
>  	machine_power_off();
> 
> 







[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2005-08-07 12:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m1mzo9eb8q.fsf@ebiederm.dsl.xmission.com>
     [not found] ` <m1iryxeb4t.fsf@ebiederm.dsl.xmission.com>
2005-07-26 17:54   ` [PATCH 1/23] Add missing device_suspsend(PMSG_FREEZE) calls Nigel Cunningham
2005-07-28  1:12     ` Eric W. Biederman
2005-07-28  2:21       ` david-b
2005-07-28  2:44       ` Shaohua Li
     [not found] ` <20050727025923.7baa38c9.akpm@osdl.org>
     [not found]   ` <m1k6jc9sdr.fsf@ebiederm.dsl.xmission.com>
     [not found]     ` <20050727104123.7938477a.akpm@osdl.org>
     [not found]       ` <m18xzs9ktc.fsf@ebiederm.dsl.xmission.com>
     [not found]         ` <20050727224711.GA6671@elf.ucw.cz>
     [not found]           ` <20050727155118.6d67d48e.akpm@osdl.org>
     [not found]             ` <20050727225442.GD6529@elf.ucw.cz>
     [not found]               ` <1123125850.948.9.camel@localhost>
     [not found]                 ` <20050804214520.GF1780@elf.ucw.cz>
     [not found]                   ` <m1ackah4r3.fsf@ebiederm.dsl.xmission.com>
     [not found]                     ` <20050725161548.274d3d67.akpm@osdl.org>
     [not found]                       ` <dnpst4v5px.fsf@magla.zg.iskon.hr>
     [not found]                         ` <m1oe8o9stl.fsf@ebiederm.dsl.xmission.com>
     [not found]                           ` <dny87s6oe9.fsf@magla.zg.iskon.hr>
     [not found]                             ` <m1r7dk82a4.fsf@ebiederm.dsl.xmission.com>
     [not found]                               ` <42E8439E.9030103@ribosome.natur.cuni.cz>
     [not found]                                 ` <20050727193911.2cb4df88.akpm@osdl.org>
     [not found]                                   ` <42F121CD.5070903@ribosome.natur.cuni.cz>
     [not found]                                     ` <20050803200514.3ddb8195.akpm@osdl.org>
     [not found]                                       ` <20050805140837.GA5556@localhost>
     [not found]                                         ` <42F52AC5.1060109@ribosome.natur.cuni.cz>
     [not found]                                         ` <1123193791.9025.77.camel@localhost>
2005-08-07 12:48                                           ` Eric W. Biederman [this message]
2005-08-07 19:02                                             ` FYI: device_suspend(...) in kernel_power_off() Pavel Machek
2005-08-07 19:46                                               ` Eric W. Biederman
2005-08-07 21:11                                                 ` Pavel Machek
2005-08-09 17:25                                                   ` Eric W. Biederman
2005-08-09 21:29                                                     ` Nigel Cunningham
2005-08-10 13:08                                                     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m13bplykt3.fsf_-_@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=fastboot@lists.osdl.org \
    --cc=jdomingo@24x7linux.com \
    --cc=john@illhostit.com \
    --cc=linux-kernel@24x7linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@osdl.org \
    --cc=mmokrejs@ribosome.natur.cuni.cz \
    --cc=ncunningham@cyclades.com \
    --cc=pavel@ucw.cz \
    --cc=sjordet@gmail.com \
    --cc=torvalds@osdl.org \
    --cc=zlatko.calusic@iskon.hr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox