Messages in this thread | | | Date | Sat, 25 Sep 1999 13:26:37 -0600 | From | Richard Gooch <> | Subject | Re: possible deadlock in smp_call_function() |
| |
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/
| |