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 29110 invoked from network); 15 Feb 2021 16:56:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Feb 2021 16:56:40 -0000 Received: (qmail 24058 invoked by uid 550); 15 Feb 2021 16:56:35 -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 24040 invoked from network); 15 Feb 2021 16:56:34 -0000 Date: Mon, 15 Feb 2021 11:56:22 -0500 From: Rich Felker To: Dominic Chen Cc: fweimer@redhat.com, musl@lists.openwall.com Message-ID: <20210215165622.GF11590@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210203225518.GY23432@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Incorrect thread TID caching On Wed, Feb 03, 2021 at 05:55:18PM -0500, Rich Felker wrote: > On Wed, Feb 03, 2021 at 05:30:01PM -0500, Dominic Chen wrote: > > > > On 2/3/2021 4:01 PM, Rich Felker wrote: > > >OK, raise should probably just be changed here to work even in vforked > > >child since it seems plausible someone will use it there. It's not > > >like saving the syscall actually matters here. But that's independent > > >of the clone() issue. > > > > Sounds good, thanks! > > Hm, looking at how to do this now, and if clone is going to behave > like _Fork, it needs to be able to run code in the child (to restore > the signals is masked, etc.), which means it needs to wrap the child > function passed to it. I think this is doable, but it's not entirely > trivial. 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. In theory we don't need __clone and the above-mentioned callback wrapper machinery for the non-CLONE_VM case (the only one that's safe anyway) and can just use __syscall(SYS_clone, ...) from C, and then the code from _Fork.c can just be generalized to take a function pointer and arg pointer to call back to instead of directly making the SYS_fork syscall. However, the fact that SYS_clone has arch-dependent argument order makes this painful. The extended arguments whose order vary are *mostly* invalid (you can't set a custom TLS pointer or exit futex address, at least) so perhaps we could just EINVAL them in clone(). The other option looks like it's to split the pre/post logic for _Fork out into separate functions; then clone can call the pre logic in the parent and the child function passed to __clone can call the post logic for the child. This is uglier and more costly to _Fork, and I'd like to avoid it, but not as much as I'd like to avoid duplicating logic for per-arch argument order. Hopefully we can avoid both.. Rich