Re: Re: seccomp causes pthread_join() to hang

[Szabolcs Nagy <nsz@port70.net>]

* Radostin Stoyanov <rstoyanov1@gmail.com> [2019-06-26 08:30:34 +0100]:
> On 26/06/2019 00:26, Rich Felker wrote:
> >   Any configuration
> > that results in a thread being terminated out from under the process
> > has all sorts of extremely dangerous conditions with memory/locks
> > being left in inconsistent state, tid reuse while the application
> > thinks the old thread is still alive, etc., and fundamentally can't be
> > supported. What you're seeing is exposure of a serious existing
> > problem with this seccomp usage, not a regression.
> I wrote "Regression: Yes" because this bug was recently introduced and it
> does not occur in previous versions.
> 
> IMHO causing pthread_join() to hang when a thread has been terminated is not
> expected behaviour, at least because the man page for pthread_join(3)
> states:

the point is that if *any* libc api is used in the killed thread
or a libc api is used to create that thread fundamentally breaks
assumptions the c runtime may rely on and thus *any* libc call
after the kill is undefined.

so it's not just pthread_join that's broken but *everything*.

this affects glibc too and old musl too, even if you may only
observe the particlar pthread_join problem with a current musl.

if the killed thread was in a signal handler that interrupted
arbitrary libc operation then it obviously breaks everything,
but even without that the libc will hold onto thread specific
internal state and whenever that is used it can cause problems
(in case of musl it is used in pthread_join, glibc uses it e.g.
for set*id operations)