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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28719 invoked from network); 14 Feb 2023 13:44:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 14 Feb 2023 13:44:43 -0000 Received: (qmail 1346 invoked by uid 550); 14 Feb 2023 13:44:40 -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 1313 invoked from network); 14 Feb 2023 13:44:39 -0000 Date: Tue, 14 Feb 2023 08:44:27 -0500 From: Rich Felker To: =?utf-8?B?5YWU5a2Q54yq?= <3264430019@qq.com> Cc: musl Message-ID: <20230214134426.GU4163@brightrain.aerifal.cx> References: <20230214120515.GT4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230214120515.GT4163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl][PATCH]fix tsd's issue On Tue, Feb 14, 2023 at 07:05:15AM -0500, Rich Felker wrote: > On Tue, Feb 14, 2023 at 03:25:23PM +0800, 兔子猪 wrote: > > Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows: > > 1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized. > > 2, Musl calls malloc before updating TLS size in dl stage 3. > > 3, New created initial_tls doesn't carry builtin_tls's tsd. > > > > > > The attached patch could fix this issue, please review it, thanks. > > An interposed malloc being reachable before the crt1 entry point is a > bug that needs to be fixed. This is a context where it's not valid to > call any application-provided code. Where does the call happen from? > dynlink.c itself uses the internal malloc but I guess there's > somewhere the interposable malloc is getting called indirectly from. I went looking for it and couldn't find any sign of malloc reachability unless you go back to 1.2.1. Commit c1e5d243b7e39b2fbfb17144608ce045575d8e95 removed the use via stdio, and 34952fe5de44a833370cbe87b63fb8eec61466d7 switched to internal malloc for all direct use from ldso. Are you just using a really old version? Rich