Messages in this thread | | | Date | Wed, 15 Jul 2020 12:59:43 +0200 | From | Christian Brauner <> | Subject | 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: > > > 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. > > > 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
| |