From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5722 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: PATCH: don't call cleanup handlers after a regular return from the thread start function Date: Tue, 5 Aug 2014 15:41:17 -0400 Message-ID: <20140805194117.GI1674@brightrain.aerifal.cx> References: <1407257494.24324.241.camel@eris.loria.fr> <20140805170942.GG1674@brightrain.aerifal.cx> <1407265576.24324.248.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1407267697 16926 80.91.229.3 (5 Aug 2014 19:41:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Aug 2014 19:41:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5727-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 05 21:41:31 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XEkby-0001yf-Mb for gllmg-musl@plane.gmane.org; Tue, 05 Aug 2014 21:41:30 +0200 Original-Received: (qmail 31853 invoked by uid 550); 5 Aug 2014 19:41:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31840 invoked from network); 5 Aug 2014 19:41:29 -0000 Content-Disposition: inline In-Reply-To: <1407265576.24324.248.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5722 Archived-At: On Tue, Aug 05, 2014 at 09:06:16PM +0200, Jens Gustedt wrote: > Hello, > > Am Dienstag, den 05.08.2014, 13:09 -0400 schrieb Rich Felker: > > > Linux manpages are more explicit and state: > > > > > > Clean-up handlers are not called if the thread terminates by > > > performing a return from the thread start function. > > > > > > This patch aligns musl to that behavior. > > > > Could you clarify why this patch is necessary? I think such a return > > is explicitly UB. > > > > "The effect of the use of return, break, continue, and goto to > > prematurely leave a code block described by a pair of > > pthread_cleanup_push() and pthread_cleanup_pop() functions calls is > > undefined." > > yes > > The linux man page (glibc I suppose) has no such mention, only > disallows longjmp and the phrase I cited above. I think this > establishes an extension for POSIX on Linux systems. I think what's going on here is that glibc implements cancellation cleanup as unwinding, so whatever happens to be the behavior that results from unwinding is what you get. However, I would think that would cause the cleanup handlers to get run when returning from the start function, rather than not running, since it's actually the compiler that calls them, and the compiler has no way of knowing the start function is special. musl explicitly does not use unwinding for cancellation, and does not attempt to provide related glibc semantics which are all in the realm of UB per POSIX. > But I have another reason for wanting that, future compatibility with > C threads. Programs that are written for C threads will not be aware > of such interdictions. Concretely in our case of my C thread v3 patch > a user can longjmp from a once-init-handler (written by her or him) > through pthread_once (in libc, for musl with pthread_cleanup_push) to > the thread start function (again user code) and then return from > there. (All of this seems to be allowed by POSIX) Such a longjmp is UB unless it's explicitly permitted by the standard -- same as longjmp out of qsort. There's no guarantee to a function called as a callback from the standard library that the calling function does not have internal state which would be left in an inconsistent state by longjmp'ing out. If call_once is explicitly required to support longjmp, then a separate implementation of call_once is needed for C11 without cancellation support. However I doubt this usage is supported, since the state of the once_flag would have to be specified for such interrupted calls, and I see no such specification. > I consider to not execute the cleanup handlers a little bit more > friendly than executing them. musl does not do either. It's simply UB. At the point where you're claiming the cleanup handler is executed, the pointer being dereferenced is to an object whose lifetime has ended, so it's not even making a call to the cleanup handler but simply invoking UB. > Another possibility would be to split the behavior > > - abort for pthreads (this is nicer than executing the handlers or > than silently ignore them) > > - ignore for C threads There's no way it can happen for C threads unless they're actually using pthread_cleanup_push, and the relevenat code that might be returning is aware of POSIX and the reules for use of pthread_cleanup_push. Rich