Re: [musl] Incorrect thread TID caching

[Rich Felker <dalias@libc.org>]

On Tue, Feb 02, 2021 at 11:04:23PM -0500, Dominic Chen wrote:
> I've been debugging a local port of Chrome using musl, and have
> noticed that musl is caching the thread TID in
> __pthread_self()->tid, which results in incorrect behavior if the
> application calls the clone() libc wrapper or the clone system call,
> and then calls libc functions which use the cached TID value, like
> raise().

Unfortunately it's really underdocumented and underexplored what a
child created with clone() can do. There are definitely limitations --
for example any usage with CLONE_VM or CLONE_THREAD is restricted not
to call into libc at all, and might not even be safe whatsoever.
However basic usage comparable in semantics to _Fork is probably
supposed to work at least as well as _Fork -- in particular calling
AS-safe libc functions should work.

BTW does Chrom{e,ium} itself do something with raw clone? If so this
could be a source of some of the bugs users hit, and it would be great
to get a clearer picture on what's happening.

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

I think the clone() function should be updated to provide whatever
contract we expect it to have in the cases where it's valid to use,
and this should include the same logic as in _Fork. I'm not sure what
we should have it do for unsafe/invalid usage.

> Please CC me on replies.

OK.

Rich