Module: xenomai-head
Branch: master
Commit: 9eb58f13ef476130371cb1bed4248640b05dfad6

Author: Gilles Chanteperdrix <>
Date:   Fri Jan  7 23:44:29 2011 +0100

nucleus/sched: Fix fallout of f6af9b831

By re-enabling interrupts in the middle of xnpod_suspend_thread(), f6af9b831
allows an interrupt to happen when running __xnpod_schedule() as a result of
xnshadow_relax(), right between the time xnarch_escalate() is called, and the
time the interrupts are shut off (and the nklock locked).

When this happens, __xnpod_schedule() critical section is run while the current
Adeos domain is Linux, which is precisely what xnarch_escalate() was called to

So, we simply shut interrupts off in xnpod_suspend_thread() right after
enabling them for the XNRELAX case, since this is the only place where this
issue may happen.


 ksrc/nucleus/pod.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 617c34d..d3a3122 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -1466,10 +1466,23 @@ void xnpod_suspend_thread(xnthread_t *thread, xnflags_t 
                 * shortens the uninterruptible code path.  This
                 * particular caller expects us to always return with
                 * interrupts enabled.
+                *
+                * We have to shut irqs off around xnpod_schedule()
+                * though: if an interrupt could preempt us in
+                * __xnpod_schedule right after the call to
+                * xnarch_escalate but before we lock the nklock, we
+                * would enter the critical section in xnpod_schedule
+                * while the current Adeos domain is Linux, which
+                * would defeat the purpose of having called
+                * xnarch_escalate(). xnpod_schedule() is expected to
+                * return with interrupts on.
                if (mask & XNRELAX) {
+                       splhigh(s);
+                       splexit(s);

Xenomai-git mailing list

Reply via email to