Messages in this thread | | | Date | Sat, 25 Sep 1999 21:36:14 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: possible deadlock in smp_call_function()? |
| |
On Sat, 25 Sep 1999, Richard Gooch wrote:
> > > > if (retry) { > > > > while (1) { > > > > if (smp_call_function_data) { > > > > schedule (); /* Give a mate a go */ > > > ^^^^^^^^^ > > > > yeah, i've been wondering about that one as well. Basically you have > > to be careful to either call it without the retry option, or make > > sure to not call it with spinlocks held. I'll fix this in my APIC > > patches to yield instead of pure schedule(). > > The MTRR code calls it with retry=1 and with another spinlock held, > and this is fine. [...]
mtrr.c is not really using a spinlock, it's abusing try_spinlock to implement a semaphore. It's safe to call smp_call_function() with a semaphore held.
Calling schedule() (from within process in TASK_RUNNING state) is dangerous if the process is RT, it can lead to lockups. I've already fixed this in my tree.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |