[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210204161523.GZ23432@brightrain.aerifal.cx>
Date: Thu, 4 Feb 2021 11:15:25 -0500
From: Rich Felker <dalias@...c.org>
To: Dominic Chen <d.c.ddcc@...il.com>
Cc: Carlos O'Donell <carlos@...hat.com>, musl@...ts.openwall.com,
fweimer@...hat.com
Subject: Re: Incorrect thread TID caching
On Wed, Feb 03, 2021 at 11:22:18PM -0500, Dominic Chen wrote:
>
> > On Feb 3, 2021, at 10:28 PM, Carlos O'Donell <carlos@...hat.com> wrote:
> >
> > As Rich said for musl, this is not ABI for glibc either.
> >
> > I'm not sure why you need to reset the TID cache. In glibc we have
> > containerized tests and we do not need to change internals of the
> > runtime e.g. unshare (CLONE_NEWUSER, CLONE_NEWPID, CLONE_NEWNS);
> > (see glibc/support/test-container.c).
>
>
> Thanks for the advice; sounds like I should just modify my local
> musl to call gettid directly in raise().
No, as noted earlier in this thread we should fix clone() to be like
_Fork() at least in the case where it's not doing things that are
inherently unsafe (CLONE_VM etc.) -- as long as you're making a new
process with normal process semantics, the child should be able to
safely call any AS-safe function in libc, or any function in libc at
all if the parent is not multi-threaded.
The possibility of changing raise() is just for the sake of vfork()
and is independent of the issue here.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
