[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210217210748.GL11590@brightrain.aerifal.cx>
Date: Wed, 17 Feb 2021 16:07:54 -0500
From: Rich Felker <dalias@...c.org>
To: Dominic Chen <d.c.ddcc@...il.com>
Cc: fweimer@...hat.com, musl@...ts.openwall.com
Subject: Re: Incorrect thread TID caching
On Wed, Feb 17, 2021 at 03:11:57PM -0500, Rich Felker wrote:
> On Wed, Feb 17, 2021 at 02:49:45PM -0500, Dominic Chen wrote:
> > On 2/15/2021 11:56 AM, Rich Felker wrote:
> > >Following up on this now, the code in _Fork is something I really
> > >don't want to duplicate for clone() for risk of forgetting there's a
> > >copy in the latter and letting it bitrot there. I'd rather refactor
> > >things so the same logic can be shared...
> >
> > Thanks for the update. Can you use something like
> > __attribute__((always_inline)) to just write the logic once but
> > force it to be inlined into both library functions?
>
> Whether it's inlined isn't really a big deal; this is not a hot path.
> It's more just a matter of how it needs to be split up at the source
> level, and it seems to be messy whichever way we choose.
>
> Trying to avoid calling __clone doesn't seem like such a good idea,
> since the child has to run on a new stack -- if we did avoid it we'd
> need a new way to switch stacks. The generic __unmapself has a hack
> to do this already that we could reuse without needing new
> arch-specific glue though.
>
> I'll keep trying things and see if I come up with something not too
> unreasonable.
Attached is a draft of how clone() *could* work without refactoring
the pre/post logic from _Fork to use __clone. I don't particularly
like it, and CRTJMP abuse like this (which __unmapself also does, as
noted above) is not valid for FDPIC archs (it actually expects a code
address not a function pointer). I'll try a version the other way and
see how it looks.
Rich
View attachment "clone_forklike.diff" of type "text/plain" (1358 bytes)
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.
