----- On Jul 15, 2020, at 2:31 AM, Florian Weimer fw@xxxxxxxxxxxxx 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
