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
