From: Rich Felker <dalias@libc.org>
To: Alexey Izbyshev <izbyshev@ispras.ru>
Cc: musl@lists.openwall.com
Subject: Re: __synccall: deadlock and reliance on racy /proc/self/task
Date: Sun, 10 Feb 2019 09:57:53 -0500 [thread overview]
Message-ID: <20190210145753.GE23599@brightrain.aerifal.cx> (raw)
In-Reply-To: <07389efbf06ad6903da1f92d37e1eb66@ispras.ru>
On Sun, Feb 10, 2019 at 03:15:55PM +0300, Alexey Izbyshev wrote:
> On 2019-02-10 04:20, Rich Felker wrote:
> >On Sun, Feb 10, 2019 at 02:16:23AM +0100, Szabolcs Nagy wrote:
> >>* Rich Felker <dalias@libc.org> [2019-02-09 19:52:50 -0500]:
> >>> 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.
>
> Similar to Szabolcs, I fail to see how heavier presignaling would
> help. Even if we're sure that we'll *eventually* catch all threads
> (including their future children) that were between
> __block_new_threads check in pthread_create and the clone syscall at
> the time we set __block_new_threads to 1, we still have no means to
> know whether we reached a stable state. In other words, we don't
> know when we should stop spinning in /proc/self/task loop because we
> may miss threads that are currently being created.
This seems correct.
> Also, note that __pthread_exit() blocks all signals and decrements
> libc.threads_minus_1 before exiting, so an arbitrary number of
> threads may be exiting while we're in /proc/self/task loop, and we
> know that concurrently exiting threads are related to misses.
This too -- there could in theory be unboundedly many threads that
have already decremented threads_minus_1 but haven't yet exited, and
this approach has no way to ensure that we wait for them to exit
before returning from __synccall.
I'm thinking that the problems here are unrecoverable and that we need
the thread list.
Rich
next prev parent reply other threads:[~2019-02-10 14:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-02 21:40 Alexey Izbyshev
2019-02-07 18:36 ` Rich Felker
2019-02-08 18:14 ` Alexey Izbyshev
2019-02-08 18:33 ` Rich Felker
2019-02-09 16:21 ` Szabolcs Nagy
2019-02-09 18:33 ` Alexey Izbyshev
2019-02-09 21:40 ` Szabolcs Nagy
2019-02-09 22:29 ` Alexey Izbyshev
2019-02-10 0:52 ` Rich Felker
2019-02-10 1:16 ` Szabolcs Nagy
2019-02-10 1:20 ` Rich Felker
2019-02-10 4:01 ` Rich Felker
2019-02-10 12:32 ` Szabolcs Nagy
2019-02-10 15:05 ` Rich Felker
2019-02-10 12:15 ` Alexey Izbyshev
2019-02-10 14:57 ` Rich Felker [this message]
2019-02-10 21:04 ` Alexey Izbyshev
2019-02-12 18:48 ` Rich Felker
2019-02-21 0:41 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190210145753.GE23599@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=izbyshev@ispras.ru \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).