From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7982 invoked from network); 4 Feb 2021 16:15:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 4 Feb 2021 16:15:41 -0000 Received: (qmail 11530 invoked by uid 550); 4 Feb 2021 16:15:39 -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 11512 invoked from network); 4 Feb 2021 16:15:38 -0000 Date: Thu, 4 Feb 2021 11:15:25 -0500 From: Rich Felker To: Dominic Chen Cc: Carlos O'Donell , musl@lists.openwall.com, fweimer@redhat.com Message-ID: <20210204161523.GZ23432@brightrain.aerifal.cx> References: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> <20210203192145.GW23432@brightrain.aerifal.cx> <634da58e-77d0-bea4-8ebf-f2c1fc933fee@redhat.com> <51614DF7-9976-48D3-92F2-B927FCE18663@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51614DF7-9976-48D3-92F2-B927FCE18663@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incorrect thread TID caching On Wed, Feb 03, 2021 at 11:22:18PM -0500, Dominic Chen wrote: > > > On Feb 3, 2021, at 10:28 PM, Carlos O'Donell wrote: > > > > As Rich said for musl, this is not ABI for glibc either. > > > > I'm not sure why you need to reset the TID cache. In glibc we have > > containerized tests and we do not need to change internals of the > > runtime e.g. unshare (CLONE_NEWUSER, CLONE_NEWPID, CLONE_NEWNS); > > (see glibc/support/test-container.c). > > > Thanks for the advice; sounds like I should just modify my local > musl to call gettid directly in raise(). No, as noted earlier in this thread we should fix clone() to be like _Fork() at least in the case where it's not doing things that are inherently unsafe (CLONE_VM etc.) -- as long as you're making a new process with normal process semantics, the child should be able to safely call any AS-safe function in libc, or any function in libc at all if the parent is not multi-threaded. The possibility of changing raise() is just for the sake of vfork() and is independent of the issue here. Rich