From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id c04eedf7 for ; Mon, 27 Jan 2020 20:48:27 +0000 (UTC) Received: (qmail 1277 invoked by uid 550); 27 Jan 2020 20:47:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1199 invoked from network); 27 Jan 2020 20:47:08 -0000 Date: Mon, 27 Jan 2020 15:46:56 -0500 From: Rich Felker To: musl@lists.openwall.com Cc: Simon Message-ID: <20200127204656.GC30412@brightrain.aerifal.cx> References: <20200127175154.GA30412@brightrain.aerifal.cx> <20200127203759.GS23985@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200127203759.GS23985@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Bug report: Reproduction of seg fault caused by musl thread creation race condition On Mon, Jan 27, 2020 at 09:37:59PM +0100, Szabolcs Nagy wrote: > * Simon [2020-01-27 11:59:24 -0800]: > > > Upon successful completion, pthread_create() shall store the ID > > > > > > > "Upon successfully completion" is somewhat vague wording IMO which could > > result in misinterpretation? You seem to have interpreted it as "Upon > > function completion", but surely if clone() succeeds, and the new thread > > starts running, then there is already "successful completion" even before > > pthread_create() has returned to caller? > > there is no ambiguity here. > > completion of a function call, such as pthread_create, > is well defined and it's the point that's sequenced > after the call returns, you have to synchronize with > that point to read the value from another thread. > > > This seems more specific than "Upon successful completion" but still > > doesn't exactly tie down whether the thread ID should be written before the > > the point is to not tie the behaviour down so you cannot > rely on it, this allows implementation freedom. I don't think this particular case of implementation freedom matters a lot to musl, but applications should still respect it because it may matter to implementations where more of thread creation is handled by the kernel and the thread id (in the pthread_t sense) really doesn't exist until the syscall returns. I see some good reasons for and against changing it but would probably lean towards leaving it alone as the "default course of action" -- mainly in case there are reasons against that aren't immediately apparent to us right now.. Rich