Module: xenomai-head
Branch: master
Commit: 8ade06dd81c89f3938294527e86907417291ba94
URL:    
http://git.xenomai.org/?p=xenomai-head.git;a=commit;h=8ade06dd81c89f3938294527e86907417291ba94

Author: Jan Kiszka <jan.kis...@siemens.com>
Date:   Thu Nov  5 18:28:10 2009 +0100

native: Properly update lockcnt on recursive call from secondary mode

We cannot assume that only non-recursive rt_mutex_acquire calls will
happen; the application may be buggy and come from secondary mode. Make
sure to update the user space recursion counter correctly in any case so
that at least the mutex is kept in a valid state.

Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>

---

 src/skins/native/mutex.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/src/skins/native/mutex.c b/src/skins/native/mutex.c
index 29843c7..98844ef 100644
--- a/src/skins/native/mutex.c
+++ b/src/skins/native/mutex.c
@@ -96,6 +96,20 @@ static int rt_mutex_acquire_inner(RT_MUTEX *mutex, RTIME 
timeout, xntmode_t mode
 
                if (timeout == TM_NONBLOCK && mode == XN_RELATIVE)
                        return -EWOULDBLOCK;
+       } else if (xnsynch_fast_owner_check(mutex->fastlock, cur) == 0) {
+               /*
+                * The application is buggy as it jumped to secondary mode
+                * while holding the mutex. Nevertheless, we have to keep the
+                * mutex state consistent.
+                *
+                * We make no efforts to migrate or warn here. There is
+                * CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX to catch such bugs.
+                */
+               if (mutex->lockcnt == UINT_MAX)
+                       return -EAGAIN;
+
+               mutex->lockcnt++;
+               return 0;
        }
 #endif /* CONFIG_XENO_FASTSYNCH */
 


_______________________________________________
Xenomai-git mailing list
Xenomai-git@gna.org
https://mail.gna.org/listinfo/xenomai-git

Reply via email to