[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 9 Feb 2019 20:20:32 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com, Alexey Izbyshev <izbyshev@...ras.ru>
Subject: Re: __synccall: deadlock and reliance on racy /proc/self/task
On Sun, Feb 10, 2019 at 02:16:23AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-02-09 19:52:50 -0500]:
> > On Sat, Feb 09, 2019 at 10:40:45PM +0100, Szabolcs Nagy wrote:
> > > the assumption is that if /proc/self/task is read twice such that
> > > all tids in it seem to be active and caught, then all the active
> > > threads of the process are caught (no new threads that are already
> > > started but not visible there yet)
> >
> > I'm skeptical of whether this should work in principle. If the first
> > scan of /proc/self/task misses tid J, and during the next scan, tid J
> > creates tid K then exits, it seems like we could see the same set of
> > tids on both scans.
> >
> > Maybe it's salvagable though. Since __block_new_threads is true, in
> > order for this to happen, tid J must have been between the
> > __block_new_threads check in pthread_create and the clone syscall at
> > the time __synccall started. The number of threads in such a state
> > seems to be bounded by some small constant (like 2) times
> > libc.threads_minus_1+1, computed at any point after
> > __block_new_threads is set to true, so sufficiently heavy presignaling
> > (heavier than we have now) might suffice to guarantee that all are
> > captured.
>
> heavier presignaling may catch more threads, but we don't
> know how long should we wait until all signal handlers are
> invoked (to ensure that all tasks are enqueued on the call
> serializer chain before we start walking that list)
That's why reading /proc/self/task is still necessary. However, it
seems useful to be able to prove you've queued enough signals that at
least as many threads as could possibly exist are already in a state
where they cannot return from a syscall with signals unblocked without
entering the signal handler. In that case you would know there's no
more racing going on to create new threads, so reading /proc/self/task
is purely to get the list of threads you're waiting to enqueue
themselves on the chain, not to find new threads you need to signal.
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.
