Module: xenomai-2.6
Branch: wip/localinfo
Commit: 71398ac6453ed9db214469947bafab05761a19a1
URL:
http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=71398ac6453ed9db214469947bafab05761a19a1
Author: Philippe Gerum <r...@xenomai.org>
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
timeout,
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))
xnthread_inc_rescnt(curr);
return 0;
_______________________________________________
Xenomai-git mailing list
Xenomai-git@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai-git
