[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220725164005.GG2860372@paulmck-ThinkPad-P17-Gen-1>
Date: Mon, 25 Jul 2022 09:40:05 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org,
netdev@...r.kernel.org, linux-doc@...r.kernel.org, corbet@....net,
ast@...nel.org, andrii@...nel.org, kafai@...com,
songliubraving@...com, yhs@...com, john.fastabend@...il.com,
kpsingh@...nel.org, kernel-team@...com
Subject: Re: [PATCH bpf 2/2] bpf: Update bpf_design_QA.rst to clarify that
attaching to functions is not ABI
On Mon, Jul 25, 2022 at 01:15:49PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 22, 2022 at 02:23:46PM -0700, Paul E. McKenney wrote:
> > On Fri, Jul 22, 2022 at 10:17:57PM +0200, Daniel Borkmann wrote:
> > > Otherwise I think this could be a bit misunderstood, e.g. most of the networking
> > > programs (e.g. XDP, tc, sock_addr) have a fixed framework around them where
> > > attaching programs is part of ABI.
> >
> > Excellent point, thank you!
> >
> > Apologies for the newbie question, but does BTF_ID() mark a function as
> > ABI from the viewpoing of a BPF program calling that function, attaching
> > to that function, or both? Either way, is it worth mentioning this
> > in this QA entry?
>
> Not necessarily. For example, __filemap_add_folio has a BTF_ID(), but
> it is not ABI (it's error injection).
OK, sounds like something to leave out of the QA, then.
Thanx, Paul
> > The updated patch below just adds the "arbitrary".
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit 89659e20d11fc1350f5881ff7c9687289806b2ba
> > Author: Paul E. McKenney <paulmck@...nel.org>
> > Date: Fri Jul 22 10:52:05 2022 -0700
> >
> > bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI
> >
> > This patch updates bpf_design_QA.rst to clarify that the ability to
> > attach a BPF program to an arbitrary function in the kernel does not
> > make that function become part of the Linux kernel's ABI.
> >
> > [ paulmck: Apply Daniel Borkmann feedback. ]
> >
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> >
> > diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
> > index 2ed9128cfbec8..a06ae8a828e3d 100644
> > --- a/Documentation/bpf/bpf_design_QA.rst
> > +++ b/Documentation/bpf/bpf_design_QA.rst
> > @@ -279,3 +279,15 @@ cc (congestion-control) implementations. If any of these kernel
> > functions has changed, both the in-tree and out-of-tree kernel tcp cc
> > implementations have to be changed. The same goes for the bpf
> > programs and they have to be adjusted accordingly.
> > +
> > +Q: Attaching to arbitrary kernel functions is an ABI?
> > +-----------------------------------------------------
> > +Q: BPF programs can be attached to many kernel functions. Do these
> > +kernel functions become part of the ABI?
> > +
> > +A: NO.
> > +
> > +The kernel function prototypes will change, and BPF programs attaching to
> > +them will need to change. The BPF compile-once-run-everywhere (CO-RE)
> > +should be used in order to make it easier to adapt your BPF programs to
> > +different versions of the kernel.
Powered by blists - more mailing lists