----- On Jun 14, 2018, at 9:32 AM, Florian Weimer fwei...@redhat.com wrote:
> On 06/14/2018 03:25 PM, Pavel Machek wrote: > >> But the proposal wanted to add a syscall to thread creation, right? >> And I believe that may be noticeable. > > We already call set_robust_list, so we could just pass a larger area to > that and the kernel could use it. Then no additional system call would > be needed in the common case (new kernel which recognizes the new area > size). > > But then we cannot use an initial-exec thread local variable for it > (although the offset from the thread pointer will still be constant, of > course). I'm wondering whether we could turn the problem around: expose a new system call allowing to register an array of pointers to per-thread data, which would be used rather than set_robust_list when available. This way, we could register both the robust list and rseq with a single system call, e.g.: enum linux_tls_area_type { LINUX_TLS_ROBUST_LIST, LINUX_TLS_RSEQ, }; struct linux_tls_area_item { enum linux_tls_area_type type; void *p; }; long sys_register_tls_areas(struct linux_tls_area_item *array, size_t nb) This would allow registering various TLS data structures with a single system call without hindering flexibility on the user-space side. For instance, we could still use initial-exec and the __rseq_abi symbol for rseq with this approach. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com