Messages in this thread | | | Date | Tue, 3 Feb 2009 06:06:48 +0100 | From | Ingo Molnar <> | Subject | Re: PCI PM: Restore standard config registers of all devices early |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 3 Feb 2009, Benjamin Herrenschmidt wrote: > > > > IE, you should have something to ensure, before you turn interrupts off, > > that nobody else is inside the AML interpreter. You already know there > > are no other CPUs, so it's just a matter of making sure no other process > > has scheduled while holding that mutex. > > > > The easy way to do that is to do something like taking the mutex > > yourself and then setting a flag so that the intepreter stops trying to > > take it or release it itself, maybe just using the global system state. > > > > Then release the mutex on resume. > > Why do you think this improves on anything? > > Basically, it turns the mutex into a non-entity - but if your whole > argument is that it might as well be a non-entity because nobody else can > take it anyway, then why not just leave it around? > > IOW, if your argument boils down to "there can be no contention", then you > might as well say "just use the mutex, it will never block". > > So the only thing you really need is to just disable the _debugging_ code > that mutexes have (if they get built with debugging in the first place). > > I can't find the bothersome code anyway: I do find > > DEBUG_LOCKS_WARN_ON(in_interrupt()); > > but that's just saying that you shouldn't be using mutexes from > interrupts, not from irq-off segments. There's probably something I'm > missing, like the preempt_check_resched() causing a schedule event with > irq's disabled, and the "might_sleep()" thing. But the latter should > already be disabled by the "system_state != SYSTEM_RUNNING" thing.
Mutexes should work just fine in irqs-off sections - they'll safely save/restore interrupts, even the debug variants.
We used to have code in the mutex code that unconditionally enabled interrupts (a spin_unlock_irq() iirc) - but we fixed that pretty early on because it surprised some early boot code. Maybe this is the case you remember?
Ingo
| |