----- On Jul 6, 2020, at 1:50 PM, Florian Weimer fweimer@xxxxxxxxxx wrote: > * Mathieu Desnoyers: > >> Now we need to discuss how we introduce that fix in a way that will >> allow user-space to trust the __rseq_abi.cpu_id field's content. > > I don't think that's necessary. We can mention it in the glibc > distribution notes on the wiki. > >> The usual approach to kernel bug fixing is typically to push the fix, >> mark it for stable kernels, and expect everyone to pick up the >> fixes. I wonder how comfortable glibc would be to replace its >> sched_getcpu implementation with a broken-until-fixed kernel rseq >> implementation without any mechanism in place to know whether it can >> trust the value of the cpu_id field. I am extremely reluctant to do >> so. > > We have already had similar regressions in sched_getcpu, and we didn't > put anything into glibc to deal with those. Was that acceptable because having a wrong cpu number would never trigger corruption, only slowdowns ? In the case of rseq, having the wrong cpu_id value is a real issue which will lead to corruption and crashes. So I maintain my reluctance to introduce the fix without any way for userspace to know whether the cpu_id field value is reliable. What were the reasons why it was OK to have this kind of regression in sched_getcpu in the past, and are they still valid in the context of rseq ? Thanks, Mathieu > > Just queue the fix for the stable kernels. I expect that all > distributions track stable kernel branches in some way, so just put into > the kernel commit message that this commit is needed for a working > sched_getcpu in glibc 2.32 and later. > > Once the upstream fix is in Linus' tree, I'm going to file a request to > backport the fix into the Red Hat Enterprise Linux 8. > > Thanks for finding the root cause so quickly, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
