Re: [PATCH bpf 2/2] bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI

["Paul E. McKenney" <paulmck@kernel.org>]

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@kernel.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@kernel.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.