Module: xenomai-jki
Branch: for-upstream
Commit: 13ee2a1a89b6cb2708b9a775b97742bf74e1871a

Author: Jan Kiszka <>
Date:   Sun Apr 25 16:20:51 2010 +0200

nucleus: Fix bogus lock stealing case

See "deny_stealing" mutex test case for the detailed scenario. The bug
was caused by XNWAKEN/wwake remaining untouched when returning from
xnsynch_acquire with the lock held. Namely, the robbed original owner
restarted the acquisition and grabbed the lock in the fast path without
properly resetting XNWAKEN. This happens now right after returning from
xnpod_suspend_thread (we can only gain this state when entering

Signed-off-by: Jan Kiszka <>


 ksrc/nucleus/synch.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
index 619929e..026d327 100644
--- a/ksrc/nucleus/synch.c
+++ b/ksrc/nucleus/synch.c
@@ -518,6 +518,9 @@ xnflags_t xnsynch_acquire(struct xnsynch *synch, xnticks_t 
        xnpod_suspend_thread(thread, XNPEND, timeout, timeout_mode, synch);
+       thread->wwake = NULL;
+       xnthread_clear_info(thread, XNWAKEN);
        if (xnthread_test_info(thread, XNRMID | XNTIMEO | XNBREAK))
                goto unlock_and_exit;
@@ -552,9 +555,6 @@ xnflags_t xnsynch_acquire(struct xnsynch *synch, xnticks_t 
-       thread->wwake = NULL;
-       xnthread_clear_info(thread, XNWAKEN);
        xnlock_put_irqrestore(&nklock, s);
        return xnthread_test_info(thread, XNRMID|XNTIMEO|XNBREAK);

Xenomai-git mailing list

Reply via email to