Messages in this thread | | | Date | Wed, 15 Jul 2020 10:38:22 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq |
| |
----- On Jul 15, 2020, at 2:31 AM, Florian Weimer fw@deneb.enyo.de wrote:
> * Chris Kennelly: > >> When glibc provides registration, is the anticipated use case that a >> library would unregister and reregister each thread to "upgrade" it to >> the most modern version of interface it knows about provided by the >> kernel? > > Absolutely not, that is likely to break other consumers because an > expected rseq area becomes dormant instead.
Indeed.
> >> There, I could assume an all-or-nothing registration of the new >> feature--limited only by kernel availability for thread >> homogeneity--but inconsistencies across early adopter libraries would >> mean each thread would have to examine its own TLS to determine if a >> feature were available. > > Exactly. Certain uses of seccomp can also have this effect, > presenting a non-homogeneous view.
The nice thing about having a consistent feature-set for a given thread group is that it allows specializing the code at thread group startup, rather than requiring to dynamically check for feature availability at runtime in fast-paths.
I wonder whether this kind of non-homogeneous view scenario caused by seccomp is something we should support, or something that should be documented as incompatible with rseq ?
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |