Re: [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix
I would like to point out that the subject is misleading: This is not an ABI change. It fixes the contents of the __rseq_abi TLS variable (as glibc calls it), but that's it. (Sorry, I should have mentioned this earlier.)
Re: [RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix
* Mathieu Desnoyers: > This is an RFC aiming for quick inclusion into the Linux kernel, unless > we prefer reverting the entire rseq glibc integration and try again in 6 > months. Their upcoming release is on August 3rd, so we need to take a > decision on this matter quickly. Just to clarify here, I don't think it's necessary to change glibc so that it only enables the rseq functionality if this particular bug is not present. From our perspective, it's just another kernel bug. If you truly feel we must not enable this feature in its present kernel state, then we need a working patch on all sides by the end of the week because the hard ABI freeze for glibc 2.32 is coming up, and at without any other patches, the only safe choice to prevent glibc from using slightly broken rseq support would be to back out the rseq patches. But again, I don't think such drastic action is necessary.
[RFC PATCH for 5.8 0/4] rseq cpu_id ABI fix
Hi, Recent integration of rseq into glibc unearthed an issue with inaccurate cpu_id field for newly created tasks. This series includes a fix for the underlying issue (meant to be backported to stable), as well as new rseq flags to let user-space know that the kernel implements this fix, so glibc and other rseq users can use this flag to know whether they can safely use rseq without risk of corrupting their per-cpu data. This new flag could either be added only to the master branch (no stable backport) or backported to stable, depending on what seems the most appropriate. This is an RFC aiming for quick inclusion into the Linux kernel, unless we prefer reverting the entire rseq glibc integration and try again in 6 months. Their upcoming release is on August 3rd, so we need to take a decision on this matter quickly. Thanks, Mathieu Mathieu Desnoyers (4): sched: Fix unreliable rseq cpu_id for new tasks rseq: Introduce RSEQ_FLAG_REGISTER rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID rseq: selftests: Expect reliable cpu_id field include/uapi/linux/rseq.h | 15 +- kernel/rseq.c | 81 - kernel/sched/core.c | 2 + tools/testing/selftests/rseq/rseq.c | 10 +++- 4 files changed, 71 insertions(+), 37 deletions(-) -- 2.17.1
