Re: possible deadlock in smp_call_function()

Richard Gooch (rgooch@ras.ucalgary.ca)
Sat, 25 Sep 1999 13:26:37 -0600


manfreds@colorfullife.com writes:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > In fact is there any reason the lock on smp_call_function isnt just a
> > semaphore acting as a queue manager ?

Hm. Let me ponder the implications of that.

> I don't know, most likely this is legacy code: perhaps it was
> written before down_trylock() was implemented.

I wrote smp_call_function() January this year. Does that count as
legacy?

> I checked the other architectures:
> smp_call_function is a "portable" function, but it's only implemented for
> i386 and alpha.
> alpha: implementation identical to i386, they also use schedule().
>
> it's currently used for:
> * i386: MTRR.

That's why it was written.

> * alpha: smp tlb flushing.

Nice to see someone discovered it and decided it was worth porting.

> I'll replace spinlock and schedule() with a normal semaphore and
> down()/down_trylock().

That may be OK, but I don't see the necessity.

> Ingo, could you also fix the UP version of smp_call_function in
> <linux/smp.h>?
> line 84:
> - #define smp_call_function(func,info,retry,wait)
> + #define smp_call_function(func,info,retry,wait) (func,info,retry,wait,
> 0)

Erk, NO! smp_call_function() is designed *not* to call the function
for the local CPU! The MTRR code relies on this! This should not be
changed.

Regards,

Richard....
Old: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
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/