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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 3673 invoked from network); 3 Feb 2021 07:16:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Feb 2021 07:16:52 -0000 Received: (qmail 28041 invoked by uid 550); 3 Feb 2021 07:16:46 -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 28021 invoked from network); 3 Feb 2021 07:16:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612336594; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=M/KXdLCf9GzrIdrDj0I8GxoktrxeSnYYp/AD2r31owE=; b=iuDpTVsDcYlp5TvVlgSqlTxzttb1b/c5xkmV8mFU6sV1X6XqG7pjtHTHY4MEWTLT6fZmix v5QjJyJ3j1NCFXSit7TwLCnrxvn3TsnN2JzWFECZ5i1RTJ8UfPlEqxVkDzJRdiTUrOblsU h1+y6edj7/9mEFKHs6FVuDC1mFO4AXw= X-MC-Unique: LZJiwyXiOoW1xT5iVtdXXQ-1 From: Florian Weimer To: Dominic Chen Cc: musl@lists.openwall.com References: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> Date: Wed, 03 Feb 2021 08:16:30 +0100 In-Reply-To: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com> (Dominic Chen's message of "Tue, 2 Feb 2021 23:04:23 -0500") Message-ID: <87zh0ltycx.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [musl] Incorrect thread TID caching * Dominic Chen: > From a quick skim of other libc implementations, both bionic and glibc > don't seem to cache TID, and directly call the gettid system call > inside raise(). Of course glibc has a TID cache. It doesn't use it in raise (mostly to get abort working after vfork), but it's definitely needed in other places. If you use the clone system call wrapper in threading (not fork/vfork) mode, you cannot call any libc functions afterwards, including the syscall function. Instead, you have to issue direct system calls. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill