On Fri, 31 Jul 2009 08:47:02 am Dave Jones wrote: > On Fri, Jul 31, 2009 at 08:37:22AM +0930, Rusty Russell wrote: > > Yeah, I was confused: my patch changed set_cpus_allowed_ptr() to > > an smp_call_function. If the latter is a bad idea with irqs disabled, the > > former certainly was... > > Right, the only reason reverting your change 'fixes' the problem is > that we don't have a BUG() in set_cpus_allowed_ptr to check for interrupts > being disabled. Exactly. > hmm, does adding an equivalent check make sense? > cpufreq seemed to cope just fine when we used set_cpus_allowed_ptr, > but we might have just got lucky. As we were suspending in this path, > interaction from the scheduler is minimal. Other callers might not > be so lucky? If someone who knows the code can verify that, in fact, we are always on the right CPU, we can eliminate it altogether. I'm not happy with a "probably get lucky" scenario... Rusty. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
