On Fri, Jul 22, 2022 at 10:17:57PM +0200, Daniel Borkmann wrote:
> On 7/22/22 8:06 PM, Paul E. McKenney wrote:
> > This patch updates bpf_design_QA.rst to clarify that the ability to
> > attach a BPF program to a given function in the kernel does not make
> > that function become part of the Linux kernel's ABI.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> > ---
> > Documentation/bpf/bpf_design_QA.rst | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
> > index 2ed9128cfbec8..46337a60255e9 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 kernel functions is an ABI?
>
> small nit, I'd change to: Attaching to arbitrary kernel functions [...]
>
> 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?
The updated patch below just adds the "arbitrary".
Thanx, Paul
------------------------------------------------------------------------
commit 89659e20d11fc1350f5881ff7c9687289806b2ba
Author: Paul E. McKenney <paulmck@xxxxxxxxxx>
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@xxxxxxxxxx>
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.
