Messages in this thread | | | From | Szabolcs Nagy <> | Subject | Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation | Date | Thu, 22 Nov 2018 16:24:56 +0000 |
| |
On 22/11/18 15:33, Mathieu Desnoyers wrote: > ----- On Nov 22, 2018, at 10:21 AM, Florian Weimer fweimer@redhat.com wrote: >> Right, but in case of user-supplied stacks, we actually free TLS memory >> at this point, so signals need to be blocked because the TCB is >> (partially) gone after that. > > Unfortuntately, disabling signals is not enough. > > With rseq registered, the kernel accesses the rseq TLS area when returning to > user-space after _preemption_ of user-space, which can be triggered at any > point by an interrupt or a fault, even if signals are blocked. > > So if there are cases where the TLS memory is freed while the thread is still > running, we _need_ to explicitly unregister rseq beforehand.
i think the man page should point this out.
the memory of a registered rseq object must not be freed before thread exit. (either unregister it or free later)
and ideally also point out that c language thread storage duration does not provide this guarantee: it may be freed by the implementation before thread exit (which is currently not observable, but with the rseq syscall it is).
| |