Philippe Gerum authored Nov 24, 2019 and Jan Kiszka committed Nov 25, 2019

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>