lkml.org 
[lkml]   [1999]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.023 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site