Re: possible deadlock in smp_call_function()?

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

Manfred Spraul writes:
> if the smp_function area is busy, then smp_call_function() executes the
> following code:
>
> > if (retry) {
> > while (1) {
> > if (smp_call_function_data) {
> > schedule (); /* Give a mate a go */
> ^^^^^^^^^
> > continue;
> > }
> > spin_lock (&lock);
> > if (smp_call_function_data) {
> > spin_unlock (&lock); /* Bad luck */
> > continue;
> > }
> > /* Mine, all mine! */
> > break;
> > }
> > }
>
> Is that ok?

I think it's fine (I'm the author, BTW).

> e.g what if the current thread is a realtime thread, could this
> deadlock? Is is possible that schedule() will never return?

The current thread *is* the one calling smp_call_function().
Or are you thinking about calling smp_call_function() from outside a
process context? You're not supposed to do that. Therefore it's not a
problem ;-)

> I've written a small patch which enables _PAGE_GLOBAL for module
> memory, but currently, the kernel locks hard during X startup.

Erm, is this related to smp_call_function()?

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/