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 10219f39 for ; Mon, 27 Jan 2020 20:38:13 +0000 (UTC) Received: (qmail 28351 invoked by uid 550); 27 Jan 2020 20:38:11 -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 28333 invoked from network); 27 Jan 2020 20:38:11 -0000 Date: Mon, 27 Jan 2020 21:37:59 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Cc: Rich Felker , Simon Message-ID: <20200127203759.GS23985@port70.net> Mail-Followup-To: musl@lists.openwall.com, Rich Felker , Simon References: <20200127175154.GA30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Bug report: Reproduction of seg fault caused by musl thread creation race condition * 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 checked the glibc pthread_create() implementation and it appears to set > the thread ID before the new thread executes. So from that POV any code > using glibc relying on this is arguably non-portable, but not racy since > there is no race with the glibc implementation? it is racy because glibc gives no guarantee, i.e. an update may change this implementation internal detail.