Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq
From: Mathieu Desnoyers
Date: Wed Jul 15 2020 - 10:38:26 EST
----- 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