Thread (2 messages) flat view 2 messages, 2 authors, 2020-07-06

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

From: Florian Weimer <hidden>
Date: 2020-07-06 17:51:11
Also in: lkml

* 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.

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help