Re: BUG: using smp_processor_id() during suspend with 2.6.25-rc8

[Pavel Machek]

On Fri 2008-04-11 01:25:13, Jiri Kosina wrote:
> On Thu, 10 Apr 2008, Pavel Machek wrote:
> 
> > > > > 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.
> > > So, any idea why mce_resume() -> mce_init() -> debug_smp_processor_id() 
> > > triggers the warning? Apparently preempt_count is zero, irqs_disabled() 
> > > returns false, and cpumask_of_cpu() is not equal to current->cpus_allowed.

...that is okay in case of just one CPU.

> > We are single-threaded because we 'unplugged' all the other cpus... but 
> > I'm not sure the BUG() code realises that...
> 
> That's unrelated, right? The real problem here is that irqs_disabled() 
> call inside debug_smp_processor_id() signalized that interrupts are 
> enabled, and that (correctly) triggered the bug.

Well, we can discuss it personally.

Yes, it is probably bug that interrupts are enabled there. No, the bug
can't potentially bite the user because there should be just one CPU
"plugged in"... so it is kind of false-positive, too..

Does the warning go away with this?


									Pavel

diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c
index 6c90fb9..8195c37 100644
--- a/lib/smp_processor_id.c
+++ b/lib/smp_processor_id.c
@@ -35,6 +35,13 @@ unsigned int debug_smp_processor_id(void
 		goto out;
 
 	/*
+	 * It is valid to assume CPU-locality if there's just one
+	 * CPU active
+	 */
+	if (num_online_cpus() == 1)
+		goto out;
+
+	/*
 	 * Avoid recursion:
 	 */
 	preempt_disable();

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/