Re: possible deadlock in smp_call_function()?

Ingo Molnar (mingo@chiara.csoma.elte.hu)
Sat, 25 Sep 1999 21:36:14 +0200 (CEST)


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/