From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Andi Kleen <andi@firstfloor.org>,
Zdenek Kabelac <zdenek.kabelac@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
Kernel development list <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: BUG: using smp_processor_id() during suspend with 2.6.25-rc8
Date: Tue, 8 Apr 2008 00:54:27 +0200 [thread overview]
Message-ID: <200804080054.28575.rjw@sisk.pl> (raw)
In-Reply-To: <20080407223540.GI16647@one.firstfloor.org>
On Tuesday, 8 of April 2008, Andi Kleen wrote:
> On Tue, Apr 08, 2008 at 12:29:30AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 8 of April 2008, Andi Kleen wrote:
> > > On Tue, Apr 08, 2008 at 12:11:17AM +0200, Jiri Kosina wrote:
> > > > On Tue, 8 Apr 2008, Andi Kleen wrote:
> > > >
> > > > > > I know. However preempt_count is a little bit inconsistent in such cases
> > > > > > though.
> > > > > And? interrupts off beats preempt count anyways. Why did you write the
> > > > > patch? Was there a (incorrect) warning triggered?
> > > >
> > > > Reported at http://lkml.org/lkml/2008/4/7/130
> > > >
> > > > BTW is also mce_init() (called from mce_resume()) guaranteed to run with
> > > > IRQs off?
> > >
> > > [cc rafael]
> > >
> > > The mce resume is a sysdev.
> > >
> > > sysdevs were always supposed to run completely with interrupts off. If they
> > > don't anymore that's some kind of higher level resume code bug which you need
> > > to fix there, not hack around in the low level code.
> >
> > They are executed with interrupts disabled, on one CPU.
>
> Well then someone enables them incorrectly, see the report above.
Hm, well. I really don't think that ACPI or the core does it, but anyway
Zdenek, could you please apply the appended patch and see if it
produces any additional warnings?
If it doesn't, then probably one of the sysdevs does it in its ->resume()
routine, which also will be easy to check against.
> >
> > > If it does that it likely broke more code too.
> > >
> > > Obviously turning on preemption anywhere around the machine check is
> > > fatal because it touches CPU state and if you reschedule you could
> > > switch to another CPU and change or access the wrong CPU's state.
> >
> > FWIW, at the point when sysdevs are resumed we are single-threaded.
>
> You mean single CPUed? Even a single thread could switch to another CPU.
Signle CPUed too.
Thanks,
Rafael
---
---
drivers/acpi/sleep/main.c | 8 ++++++++
1 file changed, 8 insertions(+)
Index: linux-2.6/drivers/acpi/sleep/main.c
===================================================================
--- linux-2.6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6/drivers/acpi/sleep/main.c
@@ -141,9 +141,13 @@ static int acpi_pm_enter(suspend_state_t
break;
}
+ WARN_ON(!irqs_disabled());
+
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
+ WARN_ON(!irqs_disabled());
+
/* ACPI 3.0 specs (P62) says that it's the responsibility
* of the OSPM to clear the status bit [ implying that the
* POWER_BUTTON event should not reach userspace ]
@@ -158,6 +162,8 @@ static int acpi_pm_enter(suspend_state_t
*/
acpi_hw_disable_all_gpes();
+ WARN_ON(!irqs_disabled());
+
local_irq_restore(flags);
printk(KERN_DEBUG "Back to C!\n");
@@ -165,6 +171,8 @@ static int acpi_pm_enter(suspend_state_t
if (acpi_state == ACPI_STATE_S3)
acpi_restore_state_mem();
+ WARN_ON(!irqs_disabled());
+
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
}
next prev parent reply other threads:[~2008-04-07 22:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-07 13:25 BUG: using smp_processor_id() during suspend with 2.6.25-rc8 Zdenek Kabelac
2008-04-07 21:54 ` Jiri Kosina
2008-04-07 22:02 ` Andi Kleen
2008-04-07 22:04 ` Jiri Kosina
2008-04-07 22:12 ` Andi Kleen
2008-04-07 22:11 ` Jiri Kosina
2008-04-07 22:14 ` Jiri Kosina
2008-04-07 22:23 ` Andi Kleen
2008-04-07 22:29 ` Rafael J. Wysocki
2008-04-07 22:33 ` Jiri Kosina
2008-04-07 22:53 ` Zdenek Kabelac
2008-04-07 23:10 ` Rafael J. Wysocki
2008-04-08 8:09 ` Jiri Kosina
2008-04-10 11:16 ` Zdenek Kabelac
2008-04-07 22:56 ` Rafael J. Wysocki
2008-04-10 9:45 ` Pavel Machek
2008-04-10 23:25 ` Jiri Kosina
2008-04-11 10:49 ` Pavel Machek
2008-04-11 10:51 ` Ingo Molnar
2008-04-11 10:54 ` Pavel Machek
2008-04-11 11:09 ` Ingo Molnar
2008-04-12 9:51 ` Pavel Machek
2008-04-11 15:29 ` Rafael J. Wysocki
2008-04-11 11:37 ` Andi Kleen
2008-04-11 15:27 ` Rafael J. Wysocki
2008-04-07 22:35 ` Andi Kleen
2008-04-07 22:54 ` Rafael J. Wysocki [this message]
2008-04-11 10:25 ` Ingo Molnar
2008-04-11 10:34 ` Jiri Kosina
2008-04-11 10:40 ` Ingo Molnar
2008-04-11 10:39 ` Andi Kleen
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=200804080054.28575.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=andi@firstfloor.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=zdenek.kabelac@gmail.com \
/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