From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14269 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: seccomp causes pthread_join() to hang Date: Wed, 26 Jun 2019 13:25:28 +0200 Message-ID: <20190626112528.GO16415@port70.net> References: <7e5cec16-6b96-c585-98d4-86cacafbd84e@gmail.com> <20190625232617.GK1506@brightrain.aerifal.cx> <28623527-b159-c1a8-01f2-394049f13836@gmail.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="163102"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Rich Felker , "Andrei Vagin (C)" , gorcunov@gmail.com To: musl@lists.openwall.com Original-X-From: musl-return-14285-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 26 13:25:45 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hg63c-000gJS-Ok for gllmg-musl@m.gmane.org; Wed, 26 Jun 2019 13:25:44 +0200 Original-Received: (qmail 32637 invoked by uid 550); 26 Jun 2019 11:25:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32612 invoked from network); 26 Jun 2019 11:25:40 -0000 Mail-Followup-To: musl@lists.openwall.com, Rich Felker , "Andrei Vagin (C)" , gorcunov@gmail.com Content-Disposition: inline In-Reply-To: <28623527-b159-c1a8-01f2-394049f13836@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14269 Archived-At: * Radostin Stoyanov [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)