Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation

From
Florian Weimer <hidden>
Date
2018-11-23 13:29:35
Also in
lkml
* Mathieu Desnoyers:
quoted
quoted
quoted
I don't think you need unregistering if the memory is initial-exec TLS
memory.  Initial-exec TLS memory is tied directly to the TCB and cannot
be freed while the thread is running, so it should be safe to put the
rseq area there even if glibc knows nothing about it.
Is it true for user-supplied stacks as well ?
I'm not entirely sure because the glibc terminology is confusing, but I
think it places intial-exec TLS into the static TLS area (so that it has
a fixed offset from the TCB).  The static TLS area is placed on the
user-supplied stack.
You said earlier in the email thread that user-supplied stack can be
reclaimed by __free_tcb () while the thread still runs, am I correct ?
If so, then we really want to unregister the rseq TLS before that.
No, dynamic TLS can be reclaimed.  Static TLS (which I assume includes
initial-exec TLS) is not deallocated.
I notice that __free_tcb () calls __deallocate_stack (), which invokes
_dl_deallocate_tls (). Accessing the TLS from the kernel upon preemption
would appear fragile after this call.
_dl_deallocate_tls only covers dynamic TLS.

Thanks,
Florian
Thread (1 message) 1 message, 1 author, last reply 2018-11-23
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help