Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq

On Wed, Jul 15, 2020 at 08:31:05AM +0200, Florian Weimer wrote:

* Chris Kennelly:

quoted

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.

quoted

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.

Fwiw, I pointed this out in the discussions that led up to this
patchset. I don't see how this can work if threads don't check for their
feature set.

Exactly.  Certain uses of seccomp can also have this effect,
presenting a non-homogeneous view.

Good point. There might be threads with a seccomp filter that would
block rseq features is what you mean, I assume.

Christian