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_ADSP_CUSTOM_MED,
	DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 14373 invoked from network); 3 Feb 2021 04:04:41 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 3 Feb 2021 04:04:41 -0000
Received: (qmail 1211 invoked by uid 550); 3 Feb 2021 04:04:36 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 1181 invoked from network); 3 Feb 2021 04:04:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=to:from:subject:message-id:date:mime-version
         :content-transfer-encoding:content-language;
        bh=3GGL4Qt+6GIwXZwAGTiOMyCw8w+kzRRhJ/clPPcpSek=;
        b=pPyAXoBIozi+E9Oc66CK8kpUwDDcKmc2w8x0sPPNNyKRjinyqryD7oq5lZuWMBIbGh
         TdiU9jnKNC2hZ72FoC8l9luf99FLFxZMhUcCZ4nsaD4B7PE8FFy8KmMYpXpXjnRd/TJN
         BvlA5xGVRC7BKdJD2ei7iOWp3YAA3i3Ob8XUgDXqCrI2DtbVLBtp9d7KVBuiNlgPD/r5
         b/19oxRarM0pB0h8x4dMPJpqMC5q1xvnyZ5aUI7HyPujIff4Y3J6inXscncf6gL7H0Kq
         5sxlUhOD1R2g/mAHqL8TBbAF6k0+ssnxnOu+KVoZalXBJwk7BALkhy+6CISofUGyY1QM
         noOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:to:from:subject:message-id:date:mime-version
         :content-transfer-encoding:content-language;
        bh=3GGL4Qt+6GIwXZwAGTiOMyCw8w+kzRRhJ/clPPcpSek=;
        b=t8JDDPlbBXKz+djVMuj7sfu5DwvwYeBElONBaPsk/NLhk4tz8i9Z66LdIHlK9WyvfG
         J2Ncyf/mb/Nr1EHcL+8dAnfQ4mU6avxAhc2LpODteiymFvQeqTzad/Fcympv1sdfU/hf
         MzYFkw/j3eI1Pl90HRjqvxF6qRWikCyCLXbvo+odsyAtcMU3rYSej8KYXdlqdEFzlBVC
         bZZ0VPtW5KbQUZ+BGwydeOHE8ZlAWmTBDsqClynf41JG4yn5ywinIG0mJka51Klj6cdi
         ZGWnKEwSz3csUydnrwTttc55dLiqhWgP7b162jJcQKryz73uQVLYukjjGjtUs36UrhGd
         bzqQ==
X-Gm-Message-State: AOAM531ASsroNfuXO8jbi+R/Rm0f/3u5epnR8DfX4CHXbbuz1E8N3qX/
	/MyZqO1JDr/AFUKUPeBjaWCJ1Yzod8Y=
X-Google-Smtp-Source: ABdhPJzOC7QKCGPESG2hmaIN8Ed94DoKMOzEgHp8oY0ipNnKeBoj9A/th79tpjFBuTqmf0VWGmnoEQ==
X-Received: by 2002:a37:8884:: with SMTP id k126mr924353qkd.104.1612325063987;
        Tue, 02 Feb 2021 20:04:23 -0800 (PST)
To: musl@lists.openwall.com
From: Dominic Chen <d.c.ddcc@gmail.com>
Message-ID: <62be4b85-4a42-413e-a83f-866eab4d601a@gmail.com>
Date: Tue, 2 Feb 2021 23:04:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: [musl] Incorrect thread TID caching

I've been debugging a local port of Chrome using musl, and have noticed=20
that musl is caching the thread TID in __pthread_self()->tid, which=20
results in incorrect behavior if the application calls the clone() libc=20
wrapper or the clone system call, and then calls libc functions which=20
use the cached TID value, like raise().

 From a quick skim of other libc implementations, both bionic and glibc=20
don't seem to cache TID, and directly call the gettid system call inside =

raise(). I also recall that glibc removed PID caching a few years ago=20
due to similar issues there as well. So, it seems that musl should=20
either not cache the TID, or at least update the cached value after=20
returning from the system call inside the clone() wrapper (with special=20
handling for CLONE_VM/CLONE_VFORK)?

Please CC me on replies.

Thanks,

Dominic