[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e5da694de18278946f88e7d030a72e8a18495a45.camel@gmail.com>
Date: Wed, 05 Feb 2025 11:17:18 +0100
From: Daniele Personal <d.dario76@...il.com>
To: Rich Felker <dalias@...c.org>, Florian Weimer <fweimer@...hat.com>
Cc: musl@...ts.openwall.com
Subject: Re: pthread_mutex_t shared between processes with different
pid namespaces
On Tue, 2025-02-04 at 13:53 -0500, Rich Felker wrote:
> On Mon, Feb 03, 2025 at 06:25:41PM +0100, Florian Weimer wrote:
> > * Daniele Personal:
> >
> > > On Sat, 2025-02-01 at 17:03 +0100, Florian Weimer wrote:
> > > > * Daniele Personal:
> > > >
> > > > > > Is this required for implementing the unlock-if-not-owner
> > > > > > error
> > > > > > code
> > > > > > on mutex unlock?
> > > > >
> > > > > No, I don't see problems related to EOWNERDEAD.
> > > >
> > > > Sorry, what I meant is that the TID is needed for efficient
> > > > reporting
> > > > of
> > > > usage errors. It's not imposed by the robust list protocol as
> > > > such..
> > > > There could be a PID-namespace-compatible robust mutex type
> > > > that does
> > > > not have this problem (but with less error checking).
> > > >
> > > > Thanks,
> > > > Florian
> > > >
> > >
> > > Are you saying that there are pthread_mutexes which can be shared
> > > across processes run on different pid namespaces? If yes I'm
> > > definitely
> > > interested on this. Can you tell me something more?
> >
> > You would have to add a new mutex type that is a mix of
> > PTHREAD_MUTEX_NORMAL amd PTHREAD_MUTEX_ROBUST. Closer to the
> > latter,
> > but without the ownership checks.
>
> This is inaccurate. Robust mutexes fundamentally depend on having the
> owner's tid in the owner field, and on this value not matching the
> tid
> of any other task that might hold the mutex. If these properties
> don't
> hold, the mutex may fail to unlock when the owner dies, or
> incorrectly
> unlock when another task mimicking the owner dies.
>
> The Linux robust mutex protocol fundamentally does not work across
> pid
> namespaces.
>
> Rich
Looking at the code for musl 1.2.4, a pthread_mutex_t which has been
initialized as shared and robust but not PI capable leaves uncovered
only the case of pthread_mutex_unlock().
int __pthread_mutex_unlock(pthread_mutex_t *m)
{
pthread_t self;
int waiters = m->_m_waiters;
int cont;
int type = m->_m_type & 15; <== type = 4 (robust)
int priv = (m->_m_type & 128) ^ 128; <== priv = 0 (shared)
int new = 0;
int old;
if (type != PTHREAD_MUTEX_NORMAL) {
/* this is executed because type != 0 */
self = __pthread_self();
old = m->_m_lock;
int own = old & 0x3fffffff;
if (own != self->tid) <== TIDs could collide!!!
return EPERM;
if ((type&3) == PTHREAD_MUTEX_RECURSIVE && m-
>_m_count)
return m->_m_count--, 0;
^^^ not executed: type&3 = 0
if ((type&4) && (old&0x40000000))
new = 0x7fffffff;
if (!priv) {
/* this is executed */
self->robust_list.pending = &m->_m_next;
__vm_lock();
}
volatile void *prev = m->_m_prev;
volatile void *next = m->_m_next;
*(volatile void *volatile *)prev = next;
if (next != &self->robust_list.head) *(volatile void
*volatile *)
((char *)next - sizeof(void *)) = prev;
}
if (type&8) {
/* this is NOT executed: not PI capable */
if (old<0 || a_cas(&m->_m_lock, old, new)!=old) {
if (new) a_store(&m->_m_waiters, -1);
__syscall(SYS_futex, &m->_m_lock,
FUTEX_UNLOCK_PI|priv);
}
cont = 0;
waiters = 0;
} else {
/* this is executed */
cont = a_swap(&m->_m_lock, new);
}
if (type != PTHREAD_MUTEX_NORMAL && !priv) {
/* this is executed */
self->robust_list.pending = 0;
__vm_unlock();
}
if (waiters || cont<0)
__wake(&m->_m_lock, 1, priv);
return 0;
}
As mentioned by Rich, since TIDs are not unique across different
namespaces, a task might unlock a mutex hold by another one if they
have the same TID.
I don't see other possible errors, am I missing something?
Anyway, apart from the implementation which could improve or cover
corner cases, I have not found any paper which gives a clear statement
of how things should behave. Moreover it might be good to mention the
information that robust mutex protocol fundamentally does not work
across pid namespaces or with which limitations.
Daniele.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
