-
In the event that xnthread_suspend() adds blocking bit(s) to a thread which is running in primary mode on a remote CPU at the time of the call, a spurious rescheduling call is performed, causing the local CPU to pick its next thread from the remote CPU's runqueue. CPU0 CPU1 ---- ---- t2: ... t1: suspend(t2) ... | | +------> t2->sched == t2->sched->curr (i.e. running primary) | | +----> __xnsched_run(t2->sched); | | v CPU0: ___xnsched__run(CPU1.sched); IOW, CPU0 would pick the next thread from CPU1's runqueue. Conditions for observing this bug: - t1 is running in primary mode on the local CPU (such as CPU0:sched->curr == t1) , so that the rescheduling request needs no prior escalation to the head stage, allowing ___xnsched_run() to execute immediately using the sched slot pointer received from __xnsched_run(). - t2 is running in primary mode on a remote CPU (such as CPU1:sched->curr == t2) when t1 attempts to suspend it via a call to xnthread_suspend(). Signed-off-by: Philippe Gerum <rpm@xenomai.org> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
3f16906c