-
Notifications
You must be signed in to change notification settings - Fork 562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is_thread_tls_initialized() fails to distinguish a thread in a new thread group from a fork child #2089
Comments
I can reproduce the bug observed on other apps by making the linux.clone test built as PIE, which forces use of the MSR rather than the GDT and results in a crash:
|
The history here is interesting: there are multiple references to avoiding syscalls in is_thread_tls_initialized(), yet we regressed for MSR support. See get_thread_id():
Similarly:
|
Micro-benchmark: call dr_get_current_drcontext() 268 million times in empty client init:
So 6x faster. |
Testing plain debug build: Running an old already-built gtest w/ a lot of code (suid sandbox not
The ratio increases as checklevel is dropped until at -checklevel 0 it's
Release build shows non-trivial impact as well:
|
The forthcoming commit message does a good job of summarizing the design of the solution here:
|
I abandoned the initial plan of setting up the child's TLS in the parent: it was much simpler to set an invalid TLS instead. There were many complications of this around native vs DR swaps, init and exit corner cases, 32-bit vs 64-bit, etc. |
Pasting some notes on complications with thread exit that were solved, but in case we need to tweak the solution:
|
When creating client threads, we still attempted to invalidate the thread's TLS by writing a null selector to its segment register. In 64-bit mode, this seemed to work most of the time because presumably Intel and AMD are then zero'ing out the upper 32-bit of the hidden segment's base. Intel describes this in Vol. 3A 3.4.4, although not completely clear. This patch applies the same scheme introduced and described in #2089. Before this patch, the test code_api|client.thread ran into all kinds of assertions, because the client thread interfered with the parent's TLS. These failures are now gone. Fixes #3526 Issue: #2089
When creating client threads, we still attempted to invalidate the thread's TLS by writing a null selector to its segment register. In 64-bit mode, this seemed to work most of the time because presumably Intel and AMD are then zero'ing out the the hidden segment's base. Intel does _not_ adequately describe this e.g. in Vol. 3A 3.4.4. This patch applies the same scheme introduced and described in #2089. Before this patch, the test code_api|client.thread ran into all kinds of assertions, because the client thread interfered with the parent's TLS. These failures are now gone. Fixes #3526 Issue: #2089
When creating client threads, we still attempted to invalidate the thread's TLS by writing a null selector to its segment register. In 64-bit mode, this seemed to work most of the time because presumably Intel and AMD are then zero'ing out the the hidden segment's base. Intel does _not_ adequately describe this e.g. in Vol. 3A 3.4.4. This patch applies the same scheme introduced and described in #2089. Before this patch, the test code_api|client.thread ran into all kinds of assertions, because the client thread interfered with the parent's TLS. These failures are now gone. Fixes #3526 Issue: #2089
This is the problem, the || part:
A thread with CLONE_VM but not CLONE_THREAD will end up with a different thread id but will inherit the parent TLS (for use of MSR anyway where the zeroing of TLS_SEG has no effect: we plan to remove that zeroing anyway in #2088). It will pass is_thread_tls_initialized() which will wreak all kinds of havoc as it shares its parent's dcontext, resulting in strange crashes and hangs.
The plan is to redesign how is_thread_tls_initialized() works from the ground up. Xref #1986 and other cases where is_thread_tls_initialized() is also just not good enough.
The text was updated successfully, but these errors were encountered: