[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130427003730.GS20323@brightrain.aerifal.cx>
Date: Fri, 26 Apr 2013 20:37:31 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: fork, set*id(synccall), cancellation -- nasty interaction
On Fri, Apr 26, 2013 at 01:27:22PM -0400, Rich Felker wrote:
> I've run across a nasty set of race conditions I'm trying to solve:
>
> 1. __synccall, needed for multi-threaded set*id, needs to obtain a
> lock that prevents thread creation and other things. However, setuid
> and setgid are specified to be async-signal-safe. They will presently
> hang if called from a signal handler that interrupted pthread_create
> or several other functions.
I have a solution, but it's ugly and would decrease thread creation
performance by more than 10%. For static linked programs, the penalty
could be eliminated if __synccall is not used, but adding the logic to
do this would make the code much uglier.
The concept is fairly simple:
1. Fully protect the thread count by the "ptc" rwlock, so that if
another thread holds __inhibit_ptc(), the thread count can neither
increase nor decrease.
2. Prevent any calls to __synccall from interrupting code paths that
hold the "ptc" lock.
However, the requirements this translates into are:
1. pthread_create must block application signals unconditionally.
Right now it only does so in the special case of applying scheduling
changes to the new thread.
2. pthread_exit must perform the following acrobatics: First, block
application signals. Then, __acquire_ptc(). Then, block all signals,
then decrement the thread count and __release_ptc(). This adds both an
extra lock/unlock step and a second sigprocmask syscall to the exit
procedure. The two-step signal blocking is needed because, if all
signals were blocked at the time of the __acquire_ptc() call, it could
deadlock with another thread calling __synccall that had already
successfully performed __inhibit_ptc() and begun the broadcast.
3. The other user of __inhibit_ptc(), dlopen, would either need to
block signals for its duration, or the "ptc" rwlock could be replaced
by a two-way symmetric lock (allowing multiple 'readers' or multiple
'writers' but not both).
Basically, it's doable, but ugly. I'm still looking for better
solutions...
Rich
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.
