From: Dominic Chen <d.c.ddcc@gmail.com>
To: Rich Felker <dalias@libc.org>
Cc: fweimer@redhat.com, musl@lists.openwall.com
Subject: Re: [musl] Incorrect thread TID caching
Date: Fri, 12 Mar 2021 16:14:51 -0500 [thread overview]
Message-ID: <60a94ab1-4682-fd04-37ce-92d61207988d@gmail.com> (raw)
In-Reply-To: <20210217210748.GL11590@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2021-03-12 21:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 4:04 Dominic Chen
2021-02-03 7:16 ` Florian Weimer
2021-02-03 19:21 ` Rich Felker
2021-02-03 20:21 ` Dominic Chen
2021-02-03 21:01 ` Rich Felker
2021-02-03 22:30 ` Dominic Chen
2021-02-03 22:55 ` Rich Felker
2021-02-15 16:56 ` Rich Felker
2021-02-17 19:49 ` Dominic Chen
2021-02-17 20:11 ` Rich Felker
2021-02-17 21:07 ` Rich Felker
2021-03-12 21:14 ` Dominic Chen [this message]
2021-02-04 3:28 ` Carlos O'Donell
2021-02-04 4:22 ` Dominic Chen
2021-02-04 16:15 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60a94ab1-4682-fd04-37ce-92d61207988d@gmail.com \
--to=d.c.ddcc@gmail.com \
--cc=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).