----- On Jul 6, 2020, at 2:11 PM, Florian Weimer fweimer@xxxxxxxxxx wrote: > * Mathieu Desnoyers: > >> ----- 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 ? > > First of all, it's a kernel bug. It's rare that we put workarounds for > kernel bugs into glibc. > > And yes, in pretty much all cases it's just a performance issue for > sched_getcpu. When you know the CPU ID of a thread due to pinning to a > single CPU, why would you call sched_getcpu? (That's the case where you > could get corruption in theory.) > >> 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. > > Yes, for rseq itself, the scenario is somewhat different. Still, it's > just another kernel bug. There will be others. 8-/ > > From a schedule point of view, it looks tough to get the magic flag into > the mainline kernel in time for the upcoming glibc 2.32 release. If you > insist on registering rseq only if the bug is not present, we'll > probably have to back out some or all of the rseq changes. I've just submitted the fix and a the new rseq flag as RFC to lkml: https://lore.kernel.org/lkml/20200706204913.20347-1-mathieu.desnoyers@xxxxxxxxxxxx/ Let's see how quickly we can come to an agreement on this on the kernel side. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
