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
patch.
--
Gilles Chanteperdrix.
Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c (revision 507)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -1543,14 +1543,25 @@
#ifdef CONFIG_XENO_OPT_DEBUG
{
- 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))
{
show_stack(xnthread_user_task(threadin),NULL);
xnpod_fatal("blocked thread %s[%d] rescheduled?! (status=0x%lx,
sig=%d, prev=%s[%d])",
