Matrix notes: the walk VM is rejected from 7.2.7 on, by the stable bpf_loop backports

The lvh 7.2 image is 7.2.8 and rejects walk.bpf.o the way bpf-next does:
"BPF program is too large. Processed 1000001 insn", with the step
callback alone at 850k instructions, against 14k for the whole object on
6.12 and 6.18. This host runs 7.2.6 and loads it. ChangeLog-7.2.7 carries
a batch of verifier precision fixes for bpf_loop callbacks, which is where
the difference lands. Say so in the workflow header and the README; the
7.2 row keeps gating, since that is a stable kernel.

Author: julian-goldstein

.github/workflows/kernel-matrix.yml

@@ -31,9 +31,13 @@ name: kernel-matrix
 # guarded, so that 6.4 floor is for the build host only, where vmlinux.h is
 # generated from the runner's own BTF by `make bpf`. So the gating lines are
 # the LTS and stable kernels from 6.6 up. bpf-next is run but does not gate:
-# it is a moving target, and 7.3-rc4 made the walk VM's bpf_loop callbacks
-# cost 850k verifier instructions against 14k on 6.12, which is worth seeing
-# but not worth blocking a merge on until it lands in a release.
+# it is a moving target, and what it shows tends to arrive in stable soon
+# after — the walk VM's three nested bpf_loops verify in 14k instructions on
+# 6.12 and 6.18, but 7.2.7 backported a batch of verifier precision fixes
+# for bpf_loop callbacks ("backtracking shouldn't clear outer frame R1-R5
+# for callbacks" and kin), after which the same object costs 850k in `step`
+# alone and hits the 1M limit on 7.2.8 and on bpf-next. 7.2.6 still loads
+# it. That 7.2 row is a real rejection on a stable kernel, so it gates.
 
 on:
   workflow_dispatch:

README.md

@@ -478,9 +478,13 @@ buffer held before — a response head where curl's body should be.
   run also caught the 6.6 verifier rejecting the wire tap's
   `bpf_skb_load_bytes` size as possibly zero, since a verifier before
   6.9 does not narrow a register on a `!= 0` branch; the bound is now
-  rebuilt by arithmetic. bpf-next runs but does not gate: on 7.3-rc4 the
-  walk VM's `bpf_loop` callbacks cost 850k verifier instructions against
-  14k on 6.12 and hit the one-million limit. `make veristat-matrix` runs the same thing
+  rebuilt by arithmetic. bpf-next runs but does not gate. The open
+  finding is the walk VM: its three nested `bpf_loop`s verify in 14k
+  instructions on 6.12 and 6.18 and on this host's 7.2.6, but stable
+  7.2.7 backported a batch of verifier precision fixes for `bpf_loop`
+  callbacks, after which `step` alone costs 850k and the object hits the
+  one-million limit on 7.2.8 and on bpf-next. That row gates, because a
+  stable kernel rejecting it is the matrix's job to say. `make veristat-matrix` runs the same thing
   locally with lvh + a static qemu (Linux, KVM, root for the VM), and
   `make veristat` is the single-kernel check against this host.