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 7683 invoked from network); 17 Feb 2021 20:12:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2021 20:12:12 -0000 Received: (qmail 26093 invoked by uid 550); 17 Feb 2021 20:12:10 -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 26068 invoked from network); 17 Feb 2021 20:12:09 -0000 Date: Wed, 17 Feb 2021 15:11:57 -0500 From: Rich Felker To: Dominic Chen Cc: fweimer@redhat.com, musl@lists.openwall.com Message-ID: <20210217201156.GK11590@brightrain.aerifal.cx> References: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> <20210203192145.GW23432@brightrain.aerifal.cx> <20210203210149.GX23432@brightrain.aerifal.cx> <20210203225518.GY23432@brightrain.aerifal.cx> <20210215165622.GF11590@brightrain.aerifal.cx> <2e2e3693-b16a-d158-9617-99978a2b287f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e2e3693-b16a-d158-9617-99978a2b287f@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incorrect thread TID caching On Wed, Feb 17, 2021 at 02:49:45PM -0500, Dominic Chen wrote: > On 2/15/2021 11:56 AM, Rich Felker wrote: > >Following up on this now, the code in _Fork is something I really > >don't want to duplicate for clone() for risk of forgetting there's a > >copy in the latter and letting it bitrot there. I'd rather refactor > >things so the same logic can be shared... > > Thanks for the update. Can you use something like > __attribute__((always_inline)) to just write the logic once but > force it to be inlined into both library functions? Whether it's inlined isn't really a big deal; this is not a hot path. It's more just a matter of how it needs to be split up at the source level, and it seems to be messy whichever way we choose. Trying to avoid calling __clone doesn't seem like such a good idea, since the child has to run on a new stack -- if we did avoid it we'd need a new way to switch stacks. The generic __unmapself has a hack to do this already that we could reuse without needing new arch-specific glue though. I'll keep trying things and see if I come up with something not too unreasonable. Rich