From: Andi Kleen <andi@firstfloor.org>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Andi Kleen <andi@firstfloor.org>,
Zdenek Kabelac <zdenek.kabelac@gmail.com>,
Kernel development list <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
rjw@sisk.pl
Subject: Re: BUG: using smp_processor_id() during suspend with 2.6.25-rc8
Date: Tue, 8 Apr 2008 00:23:52 +0200 [thread overview]
Message-ID: <20080407222352.GG16647@one.firstfloor.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0804080008420.3896@jikos.suse.cz>
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.
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.
-Andi
next prev parent reply other threads:[~2008-04-07 22:19 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 [this message]
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
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=20080407222352.GG16647@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--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