Re: [PATCH 2/3] Linux: Use rseq in sched_getcpu if available (v9)

----- On Jul 6, 2020, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:

* Mathieu Desnoyers:

quoted

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.

quoted

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