is there a chance for a race condition in pthread_mutex_[un]lock.c?

Hi all

While squeezing my brains on some inconsistencies on the RT-NPTL
patches, I came across this issue, and I was wondering how to
fix it. Please tell me I am wrong:

In NPTL any thread can unlock a mutex locked by another thread,
right?

Now, if this is so, a race condition in the process may corrupt
the internal mutex descriptor. This would happen if thread A 
locks mutex M; as soon as it locks it goes on to update the data 
structures (namely mutex->__data.__owner and __unusers). Now 
assume that just after it receives the lock from lll_mutex_lock() 
some other thread B preempts before it has a chance to record its 
ownership and unlocks M.

Now that means that when A regains control, M is locked to NPTL,
but kernel-wise, it is not (or should not, as the kernel doesn't
really know about ownerships), but the value in the __lock 
will be out of sync with __owner.

I know is a twisted situation and that the code to cause it might
be hard to come up with, but still is an inconsistency. Scratch,
scratch...one way to solve it would be to have a lock protecting
the mutex structure, or not to allow the "not owner can unlock"
situation...[and here I run out of ideas].

Comments?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)