Date: Fri, 18 Nov 2005 18:44:54 +0100
From: Ingo Molnar <mingo@elte.hu>
To: david singleton <dsingleton@mvista.com>
Cc: Dinakar Guniguntala <dino@in.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: PI BUG with -rt13
Message-ID: <20051118174454.GA2793@elte.hu>
References: <20051117161817.GA3935@in.ibm.com> <437D0C59.1060607@mvista.com> <20051118092909.GC4858@elte.hu> <20051118132137.GA5639@in.ibm.com> <20051118132715.GA3314@elte.hu> <8311ADE9-5855-11DA-BBAB-000A959BB91E@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8311ADE9-5855-11DA-BBAB-000A959BB91E@mvista.com>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1033
Lines: 28


* david singleton <dsingleton@mvista.com> wrote:

> >both rt_mutex_free() and rt_mutex_set_owner() must be called with the
> >proper locking. David?
> 
>         Yes, the lock  needs to be protected by the robust semaphore.
>         The locking order is:
> 
>                 mmap_sem to protect the vma that holds the pthread_mutex
> 
>                 robust_sem to protect the futex_mutex chain.
> 
>                 futex_mutex - the rt_mutex associated with the 
> pthread_mutex.

well, also lock->wait_lock and lock->pi_lock. The act of making another 
thread the owner of this particular mutex must be performed carefully.  
Check out rt.c to see what locking dependencies there are. (We can also 
do a lockless cmpxchg for unlocked mutexes, under certain 
circumstances.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/