[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8735hfy6wm.ffs@tglx>
Date: Thu, 12 May 2022 01:40:57 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Delyan Kratunov <delyank@...com>,
"peterz@...radead.org" <peterz@...radead.org>
Cc: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>,
"keescook@...omium.org" <keescook@...omium.org>,
"qais.yousef@....com" <qais.yousef@....com>,
Delyan Kratunov <delyank@...com>,
"andrii@...nel.org" <andrii@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"adharmap@...cinc.com" <adharmap@...cinc.com>,
"alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
"andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>,
"ast@...nel.org" <ast@...nel.org>,
"Kenta.Tada@...y.com" <Kenta.Tada@...y.com>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bristot@...hat.com" <bristot@...hat.com>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"mingo@...nel.org" <mingo@...nel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"ed.tsai@...iatek.com" <ed.tsai@...iatek.com>,
"legion@...nel.org" <legion@...nel.org>,
"acme@...nel.org" <acme@...nel.org>,
"u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
"valentin.schneider@....com" <valentin.schneider@....com>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
"namhyung@...nel.org" <namhyung@...nel.org>
Subject: Re: [PATCH v2] sched/tracing: append prev_state to tp args instead
On Wed, May 11 2022 at 18:28, Delyan Kratunov wrote:
> Commit fa2c3254d7cf (sched/tracing: Don't re-read p->state when emitting
> sched_switch event, 2022-01-20) added a new prev_state argument to the
> sched_switch tracepoint, before the prev task_struct pointer.
>
> This reordering of arguments broke BPF programs that use the raw
> tracepoint (e.g. tp_btf programs). The type of the second argument has
> changed and existing programs that assume a task_struct* argument
> (e.g. for bpf_task_storage access) will now fail to verify.
>
> If we instead append the new argument to the end, all existing programs
> would continue to work and can conditionally extract the prev_state
> argument on supported kernel versions.
If we instead? ... would continue to work?
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
It's not too hard to actually follow documented rules. Something like
this:
"Undo the reordering and move the new argument last, which ensures
that all existing programs continue to work."
Hmm?
What's worse is that the changelog is missing a clear statement that
this is a one-time change which cannot be abused to turn tracepoints
into unmodifiable ABI as you stated in:
https://lore.kernel.org/lkml/CAEf4BzaEo+dxSRJZHQiXYrj-a3_B-eODZUxGh3HrnPjquMYFXQ@mail.gmail.com
Thanks,
tglx
Powered by blists - more mailing lists