* Mathieu Desnoyers:
----- On Jul 6, 2020, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
quoted
* 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 ?
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.
Thanks,
Florian
----- On Jul 6, 2020, at 2:11 PM, Florian Weimer fweimer@redhat.com wrote:
* Mathieu Desnoyers:
quoted
----- On Jul 6, 2020, at 1:50 PM, Florian Weimer fweimer@redhat.com wrote:
quoted
* 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 ?
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.)
quoted
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@efficios.com/
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