From: "Kanoj Sarcar" <kanoj@google.engr.sgi.com>
> I am assuming you mean go from
>
> int smp_call_function (void (*func) (void *info), void *info, int
nonatomic,
> int wait)
>
> to
>
> void smp_call_function (void (*func) (void *info), void *info, int wait)
>
Yes.
> Yes, the above two are real problems. OTOH, have you walked the code
> path down under panic() to identify all the scheduling points? Seems
> to me sys_sync is another such point, maybe we should not be doing
> that too?
>
Hm. I checked the code once more: Why not? I always assumed that panic()
would be something bad, but OTHO it's often only something weird, ie we
should try to sync().
Something bad usually calls BUG(), followed by a hard lock-up on SMP ;)
> Using a spinlock instead of a sleeping lock inside smp_call_function()
> is a good idea.
>
> > * the call-back is called with disalbed interrupts, and it must not
> > reenable interrupts. [docu clarification]
>
> Shouldn't this already be happening?
Yes, it's happening, but it's nowhere documented.
>
> > * smp_call_function() itself enables interrupts, otherwise we could lock
> > up.[the current code call schedule(), and thus indirectly reenables the
> > interrupts]
>
> Umm, I don't quite see the point. Are you sure smp_call_function() is
never
> called from intr context today? Even if not today, it would be nice to
> let this happen in the future.
I really don't know. If you send an ipi with disabled interrupts, you are
inches away from a lock-up.
Remember that if cpu0 runs with disabled interrupts, it has a reason to do
so: usually, it owns an interrupt spinlock. But this means that cpu1 could
be spinning for that spinlock [with disabled local interrupts]--> lock-up.
I'll write a patch and wait for an answer from Linus.
--
Manfred
-
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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:07 EST