[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <60a94ab1-4682-fd04-37ce-92d61207988d@gmail.com>
Date: Fri, 12 Mar 2021 16:14:51 -0500
From: Dominic Chen <d.c.ddcc@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: fweimer@...hat.com, musl@...ts.openwall.com
Subject: Re: Incorrect thread TID caching
On 2/17/2021 4:07 PM, Rich Felker wrote:
>> 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.
Sorry for the delay. I did end up needing robust mutex functionality,
and ended up using a variant of your patch to fix-up. There were two
issues that I noticed:
1. Prior to CRTJMP, the 'arg' argument needs to be moved into the first
argument register for the local calling convention. I spent a little
time trying to get an architecture-neutral version working using a
wrapper function, but gave up and used some inline assembly to
populate %rdi on x86_64.
2. If a thread exits without unlocking a robust mutex, the program will
subsequently SIGSEGV since the thread's memory region has been
unmapped, but a pointer to the robust mutex remains on the internal
linked list. Not sure where the fault lies here, but just thought
I'd mention it.
Thanks,
Dominic
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.
