Module: xenomai-2.6
Branch: wip/localinfo
Commit: 71398ac6453ed9db214469947bafab05761a19a1

Author: Philippe Gerum <>
Date:   Sat Mar 11 14:17:50 2017 +0100

nucleus/synch: acquire: update owner on fast grab

This is addressing an issue detected long ago with 3.x, but overlooked
in 2.6, missing a backport. The bug would cause the mutex code to be
broken for all APIs in the !FASTSYNC case (not affecting x86, arm or
ppc), BUT also cause pthread_mutex_unlock() to return EPERM in the
FASTSYNC case in the following scenario:

- thread A grabs mutex L
- thread B contends on mutex L, takes slow syscall path for locking
- in the meantime, thread A releases mutex L
- thread B reaches xnsynch_acquire(), can do a fast grab at
synch.c:426, but fails to set the owner field in L
- thread A contends on mutex L, takes slow syscall path
- thread B releases mutex L, sees a contender so takes the slow
syscall path for unlocking, detecting a (spurious) NULL owner at
posix/syscall.c:1155, failing with EPERM although it does own the mutex
at this point.


 ksrc/nucleus/synch.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/ksrc/nucleus/synch.c b/ksrc/nucleus/synch.c
index c3b9876..1289687 100644
--- a/ksrc/nucleus/synch.c
+++ b/ksrc/nucleus/synch.c
@@ -423,6 +423,7 @@ xnflags_t xnsynch_acquire(struct xnsynch *synch, xnticks_t 
                fastlock = xnarch_atomic_cmpxchg(lockp,
                                                 XN_NO_HANDLE, threadh);
                if (likely(fastlock == XN_NO_HANDLE)) {
+                       xnsynch_set_owner(synch, curr);
                        if (xnthread_test_state(curr, XNOTHER))
                        return 0;

Xenomai-git mailing list

Reply via email to