Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
 > This is not the only situation where a thread with a nucleus suspension
 > bit need to run shortly in secondary mode: it also occurs when
 > suspending with xnpod_suspend_thread() a thread running in secondary
 > mode; the thread receives the SIGCHLD signal and need to execute shortly
 > with the suspension bit set in order to cause a migration to primary
 > mode.
> > So, the only case when we are sure that a user-space thread can not be
 > scheduled by Linux seems to be when this thread does not have the
 > XNRELAX bit.

From all the bits in XNTHREAD_BLOCK_BITS, only when the XNPEND bit is
set, a thread can not be running in secondary mode. Hence the proposed

Almost ok, but XNDELAY might also be set alone, indicating a purely timed wait state (i.e. without sync object to pend on, so XNPEND is off).


Index: ksrc/nucleus/shadow.c
--- ksrc/nucleus/shadow.c       (revision 507)
+++ ksrc/nucleus/shadow.c       (working copy)
@@ -1543,14 +1543,25 @@
-       xnflags_t status = threadin->status & ~XNRELAX;
+       xnflags_t status = threadin->status;
        int sigpending = signal_pending(next);
- if (!(next->ptrace & PT_PTRACED) &&
+        if (!testbits(status, XNRELAX))
+            {
+            show_stack(xnthread_user_task(threadin),NULL);
+            xnpod_fatal("Hardened thread %s[%d] running in Linux domain?! 
(status=0x%lx, sig=%d, prev=%s[%d])",
+                       threadin->name,
+                       next->pid,
+                       status,
+                       sigpending,
+                       prev->comm,
+                       prev->pid);
+           }
+        else if (!(next->ptrace & PT_PTRACED) &&
            /* Allow ptraced threads to run shortly in order to
               properly recover from a stopped state. */
            testbits(status,XNSTARTED) &&
-           testbits(status,XNTHREAD_BLOCK_BITS))
+           testbits(status,XNPEND))
             xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx, sig=%d, 


Xenomai-core mailing list



Reply via email to