Jan Kiszka wrote:
> Hi,
> the watchdog is currently broken in trunk ("zombie [...] would not
> die..."). In fact, it should also be broken in older versions, but only
> recent thread termination rework made this visible.
> When a Xenomai CPU hog is caught by the watchdog, xnpod_delete_thread is
> invoked, causing the current thread to be set in zombie state and
> scheduled out. But as its Linux mate still exist, hell breaks loose once
> Linux tries to get rid of it (the Xenomai zombie is scheduled in again).
> In short: calling xnpod_delete_thread(<self>) for a shadow thread is not
> working, probably never worked cleanly.

Nak, it is a regression introduced by the scheduler changes in 2.5.x. We should 
detect _any_ shadow thread that schedules out in primary mode then regains 
control in secondary mode like we do in the 2.4.x series, not only _relaxing_ 
shadow threads. It is perfectly valid to have the Linux task orphaned from the 
deletion of its shadow TCB until Xenomai notices the issue and reaps it; 
was that such regression prevented the nucleus to get the memo.

The following patch should fix the issue:

  Index: include/asm-generic/system.h
--- include/asm-generic/system.h        (revision 4676)
+++ include/asm-generic/system.h        (working copy)
@@ -311,6 +311,11 @@
        return !!s;

+static inline int xnarch_root_domain_p(void)
+       return rthal_current_domain == rthal_root_domain;
  #ifdef CONFIG_SMP

  #define xnlock_get(lock)              __xnlock_get(lock  XNLOCK_DBG_CONTEXT)
Index: ksrc/nucleus/pod.c
--- ksrc/nucleus/pod.c  (revision 4676)
+++ ksrc/nucleus/pod.c  (working copy)
@@ -2137,7 +2137,7 @@
  void __xnpod_schedule(struct xnsched *sched)
        struct xnthread *prev, *next, *curr = sched->curr;
-       int zombie, switched = 0, need_resched, relaxing;
+       int zombie, switched = 0, need_resched, shadow;
        spl_t s;

        if (xnarch_escalate())
@@ -2174,9 +2174,9 @@
                   next, xnthread_name(next));

-       relaxing = xnthread_test_state(prev, XNRELAX);
+       shadow = xnthread_test_state(prev, XNSHADOW);
-       (void)relaxing;
+       (void)shadow;

        if (xnthread_test_state(next, XNROOT)) {
@@ -2204,12 +2204,18 @@

-        * Test whether we are relaxing a thread. In such a case, we
-        * are here the epilogue of Linux' schedule, and should skip
-        * xnpod_schedule epilogue.
+        * Test whether we transitioned from primary mode to secondary
+        * over a shadow thread. This may happen in two cases:
+        *
+        * 1) the shadow thread just relaxed.
+        * 2) the shadow TCB has just been deleted, in which case
+        * we have to reap the mated Linux side as well.
+        *
+        * In both cases, we are running over the epilogue of Linux's
+        * schedule, and should skip our epilogue code.
-       if (relaxing)
-               goto relax_epilogue;
+       if (shadow && xnarch_root_domain_p())
+               goto shadow_epilogue;

        switched = 1;
@@ -2252,7 +2258,7 @@

-      relax_epilogue:
+      shadow_epilogue:
                spl_t ignored;

> There are basically two approaches to fix it: The first one is to find a
> different way to kill (or only suspend?)

Suspending the hog won't work, particularly when GDB is involved, because a 
pending non-lethal Linux signal may cause the suspended shadow to resume 
immediately for processing the signal, therefore defeating the purpose of the 
watchdog, leading to an infinite loop. This is why we moved from suspension to 
deletion upon watchdog trigger in 2.3 (2.2 used to suspend only).

  the current shadow thread when
> the watchdog strikes. The second one brought me to another issue: Raise
> SIGKILL for the current thread and make sure that it can be processed by
> Linux (e.g. via xnpod_suspend_thread(<cpu-hog>). Unfortunately, there is
> no way to force a shadow thread into secondary mode to handle pending
> Linux signals unless that thread issues a syscall once in a while. And
> that raises the question if we shouldn't improve this as well while we
> are on it.
> Granted, non-broken Xenomai user space threads always issue frequent
> syscalls, otherwise the system would starve (and the watchdog would come
> around). On the other hand, delaying signals till syscall prologues is
> different from plain Linux behaviour...
> Comments, ideas?

We probably need a two-stage approach: first record the thread was bumped out 
and suspend it from the watchdog handler to give Linux a chance to run again, 
then finish the work, killing it for good, next time the root thread is 
scheduled in on the same CPU.

> Jan
> ------------------------------------------------------------------------
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core


Xenomai-core mailing list

Reply via email to