[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190210150535.GF23599@brightrain.aerifal.cx>
Date: Sun, 10 Feb 2019 10:05:35 -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 01:32:14PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-02-09 23:01:50 -0500]:
> > On Sat, Feb 09, 2019 at 08:20:32PM -0500, Rich Felker wrote:
> > > 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)
>
> it seems if the main thread exits, it is still listed in /proc/self/task
> and has zombie status for the lifetime of the process so futex lock always
> fails with ESRCH.
>
> so my logic waiting for all exiting threads to exit does not work (at
> least the main thread needs to be special cased).
>
> > > > >
> > > > > 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.
> >
> > One thing to note: SYS_kill is not required to queue an unlimited
> > number of signals, and might not report failure to do so. We should
> > probably be using SYS_rt_sigqueue, counting the number of signals
> > successfully queued, and continue sending them during the loop that
> > monitors progress building the chain until the necessary number have
> > been successfully sent, if we're going to rely on the above properties
> > to guarantee that we've caught every thread.
>
> yes, but even if we sent enough signals that cannot be dropped,
> and see all tasks in /proc/self/task to be caught in the handler,
> there might be tasks that haven't reached the handler yet and
> not visible in /proc/self/task yet. if they add themselves to the
> chain after we start processing it then they will wait forever.
>
> as a ductape solution we could sleep a bit after all visible tasks
> are stopped to give a chance to the not yet visible ones to run
> (or to show up in /proc/self/task).
This is not going to help on a box that's swapping to hell where one
of the threads takes 30 seconds to run again (which is a real
possibility!)
> but ideally we would handle non-libc created threads too, so using
> libc.threads_minus_1 and __block_new_threads is already suboptimal,
Non-libc-created threads just can't be supported; they break in all
sorts of ways and have to just be considered totally undefined. The
synccall signal handler couldn't even perform any of the operations it
does, since libc functions all (by contract, if not in practice) rely
on having a valid thread pointer. We bend this rule slightly (and very
carefully) in posix_spawn to make syscalls with a context shared with
the thread in the parent process, but allowing it to be broken in
arbitrary ways by application code is just not practical.
> a mechanism like ptrace or SIGSTOP is needed that affects all tasks.
Yes, that would work, but is incompatible with running in an
already-traced task as far as I know.
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.
