On 22/11/18 15:33, Mathieu Desnoyers wrote: > ----- On Nov 22, 2018, at 10:21 AM, Florian Weimer [email protected] 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).
