* Mathieu Desnoyers: > Those are very good points. One possibility we have would be to let > glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID > flag. On kernels with the bug present, the cpu_id field is still good > enough for typical uses of sched_getcpu() which does not appear to > have a very strict correctness requirement on returning the right > cpu number. > > Then libraries and applications which require a reliable cpu_id > field could check this on their own by calling rseq with the > RSEQ_FLAG_RELIABLE_CPU_ID flag. This would not make the state more > complex in __rseq_abi, and let each rseq user decide about its own > fate: whether it uses rseq or keeps using an rseq-free fallback. > > I am still tempted to allow combining RSEQ_FLAG_REGISTER | > RSEQ_FLAG_RELIABLE_CPU_ID for applications which would not be using > glibc, and want to check this flag on thread registration. Well, you could add a bug fix level field to the __rseq_abi variable. Then applications could check if the kernel has the appropriate level of non-buggyness. But the same thing could be useful for many other kernel interfaces, and I haven't seen such a fix level value for them. What makes rseq so special? It won't help with the present bug, but maybe we should add an rseq API sub-call that blocks future rseq registration for the thread. Then we can add a glibc tunable that flips off rseq reliably if people do not want to use it for some reason (and switch to the non-rseq fallback code instead). But that's going to help with future bugs only.
