[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d81cfc2a865477a93591780eaa0165b88c745b3.camel@gmail.com>
Date: Tue, 04 Feb 2025 17:48:02 +0100
From: Daniele Personal <d.dario76@...il.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: pthread_mutex_t shared between processes with different
pid namespaces
On Mon, 2025-02-03 at 18:25 +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.
>
> Thanks,
> Florian
>
I wrote a stupid test to exercise things. It creates (if needed) a
shared object which will hold the pthread_mutex_t instance, mmaps it
and if the shared object has been created, initializes the mutex
(changing mutex initialization requires to delete the shared object).
Then it locks the mutex for 5 seconds, unlocks it and locks it again
after another 2 seconds and exits with the mutex locked.
I compiled the code linking to musl 1.2.4 with Yocto or for my laptop
linking to glibc 2.34 with
gcc -D_GNU_SOURCE -Wall -pthread -g -O2 -c -o main.o main.c
gcc -pthread -g -O2 -pthread -o mutex-test main.o -lrt
I have a container which is started with its own pid, mount and uts
namespaces (it shares IPC and network with the host).
Running the test separately on host and container, both can recognize
the case where the previous instance left the mutex locked and can
recover from it.
Running them in parallel gives two distinct results if the mutex is
initialized with PTHREAD_PRIO_INHERIT protocol or PTHREAD_PRIO_NONE.
If PTHREAD_PRIO_INHERIT is set, in case of contention, the waiter gets
stuck.
If PTHREAD_PRIO_NONE is used, everything seems to work fine: the
application which starts later waits for the mutex to be released by
the other one and gets waked property.
I now need to understand if this behavior is expected and reliable or
not.
Thanks in advance,
Daniele.
View attachment "main.c" of type "text/x-csrc" (11941 bytes)
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.
