Module: xenomai-head
Branch: master
Commit: 80c5f660817236de55ec4009df9d4abca539d83c

Author: Gilles Chanteperdrix <>
Date:   Tue Jan 25 10:15:51 2011 +0100

fastsync: explain invalid calls to xnheap_free

The check mutex->cpid == current->pid in rt_mutex_delete is too eager: it
will prevent mutexes from being rightfully destroyed when the ppd cleanup
callback is invoked, as in this case, the current process is not necessarily
the one which created the mutex.

The problem this check was trying to avoid was to call xnheap_free with
destroyed/wrong heap, or fastlock. But we know that xnheap_free is sufficiently 
well behaved for such a call to be harmless. So, clearly explain it in a
commentary. At this chance, fix posix skin commentary for the same case,
which no longer matched the code since commit


 ksrc/skins/native/mutex.c |    7 -------
 ksrc/skins/posix/mutex.c  |    7 ++++---
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/ksrc/skins/native/mutex.c b/ksrc/skins/native/mutex.c
index 4920d9f..9016f3f 100644
--- a/ksrc/skins/native/mutex.c
+++ b/ksrc/skins/native/mutex.c
@@ -285,13 +285,6 @@ int rt_mutex_delete(RT_MUTEX *mutex)
        global = xnsynch_test_flags(&mutex->synch_base, RT_MUTEX_EXPORTED);
-       if (!global && mutex->cpid != current->pid) {
-               err = -EINVAL;
-               goto unlock_and_exit;
-       }
        removeq(mutex->rqueue, &mutex->rlink);
        rc = xnsynch_destroy(&mutex->synch_base);
diff --git a/ksrc/skins/posix/mutex.c b/ksrc/skins/posix/mutex.c
index f4ceb87..7b69ffc 100644
--- a/ksrc/skins/posix/mutex.c
+++ b/ksrc/skins/posix/mutex.c
@@ -219,12 +219,13 @@ void pse51_mutex_destroy_internal(pse51_mutex_t *mutex,
        xnlock_put_irqrestore(&nklock, s);
+       /* We call xnheap_free even if the mutex is not pshared; when
+          this function is called from pse51_mutexq_cleanup, the
+          sem_heap is destroyed, or not the one to which the fastlock
+          belongs, xnheap will simply return an error. */
-       /* We do not free the owner if the mutex is not pshared, because when
-          this function is called from pse51_mutexq_cleanup, the sem_heap has
-          been destroyed, and we have no way to find it back. */

Xenomai-git mailing list

Reply via email to