Messages in this thread | | | Date | Wed, 8 Jul 2020 11:33:51 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH for 5.8 3/4] rseq: Introduce RSEQ_FLAG_RELIABLE_CPU_ID |
| |
[ Context for Linus: I am dropping this RFC patch, but am curious to hear your point of view on exposing to user-space which system call behavior fixes are present in the kernel, either through feature flags or system-call versioning. The intent is to allow user-space to make better decisions on whether it should use a system call or rely on fallback behavior. ]
----- On Jul 7, 2020, at 3:55 PM, Florian Weimer fw@deneb.enyo.de wrote:
> * Carlos O'Donell: > >> It's not a great fit IMO. Just let the kernel version be the arbiter of >> correctness. > > For manual review, sure. But checking it programmatically does not > yield good results due to backports. Even those who use the stable > kernel series sometimes pick up critical fixes beforehand, so it's not > reliable possible for a program to say, “I do not want to run on this > kernel because it has a bad version”. We had a recent episode of this > with the Go runtime, which tried to do exactly this.
FWIW, the kernel fix backport issue would also be a concern if we exposed a numeric "fix level version" with specific system calls: what should we do if a distribution chooses to include one fix in the sequence, but not others ? Identifying fixes are "feature flags" allow cherry-picking specific fixes in a backport, but versions would not allow that.
That being said, maybe it's not such a bad thing to _require_ the entire series of fixes to be picked in backports, which would be a fortunate side-effect of the per-syscall-fix-version approach.
But I'm under the impression that such a scheme ends up versioning a system call, which I suspect will be a no-go from Linus' perspective.
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |