lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Apr 2022 09:54:39 -0700 From: Andrii Nakryiko <andrii.nakryiko@...il.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Peter Zijlstra <peterz@...radead.org>, Delyan Kratunov <delyank@...com>, "valentin.schneider@....com" <valentin.schneider@....com>, "bigeasy@...utronix.de" <bigeasy@...utronix.de>, "dietmar.eggemann@....com" <dietmar.eggemann@....com>, "keescook@...omium.org" <keescook@...omium.org>, "andrii@...nel.org" <andrii@...nel.org>, "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "mingo@...nel.org" <mingo@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "rdunlap@...radead.org" <rdunlap@...radead.org>, "Kenta.Tada@...y.com" <Kenta.Tada@...y.com>, "adharmap@...cinc.com" <adharmap@...cinc.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "bristot@...hat.com" <bristot@...hat.com>, "ebiederm@...ssion.com" <ebiederm@...ssion.com>, "ast@...nel.org" <ast@...nel.org>, "legion@...nel.org" <legion@...nel.org>, "ed.tsai@...iatek.com" <ed.tsai@...iatek.com>, "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>, "juri.lelli@...hat.com" <juri.lelli@...hat.com>, "x86@...nel.org" <x86@...nel.org> Subject: Re: [PATCH] sched/tracing: append prev_state to tp args instead On Fri, Apr 22, 2022 at 8:56 AM Steven Rostedt <rostedt@...dmis.org> wrote: > > On Fri, 22 Apr 2022 13:09:03 +0200 > Peter Zijlstra <peterz@...radead.org> wrote: > > > If bpf wants to ride on them, it needs to suffer the pain of doing so. > > And I constantly hear that BPF is not an ABI, and is not guaranteed to work > from one kernel version to the next. Right, and that's true in terms of expectations of BPF users. But it's also true that in pracitce people's tools have to keep working across multiple kernel versions and we've developed multiple technologies (e.g., BPF CO-RE) and techniques to allow people to adapt to kernel changes. See [0] and [1] for some of the tricks people do in real production tools to accommodate kernel changes. Some kernel changes are easier to accommodate, some are harder. This particular one, though, is pretty complicated as no function or symbol got renamed, so it's much more involved to detect changes like this. But ultimately people will do that anyway. But the ask here is, given it's not too late and it's trivial to avoid this breakage in the first place by reordering function arguments, we (BPF users) kindly ask to consider doing that. Hopefully this trivial change isn't hampering kernel development in any way. [0] https://github.com/iovisor/bcc/pull/3917 [1] https://github.com/iovisor/bcc/pull/3747 > > -- Steve
Powered by blists - more mailing lists