BPF series auto-discovers fmod_ret targets via LLVM IR scan

Anton Protopopov has posted an 18-part series on the BPF list that would let the kernel build itself discover many more fmod_ret attach points, instead of relying mainly on static allowlists and declared BTF sets.

BPF modify-return programs can skip or override a kernel function’s result. That power has stayed narrow on purpose: only carefully chosen targets are safe to intercept. The series attacks the scale problem. An optional LLVM plugin, bpf_scan_ir, walks clang IR for functions that return errno-style failures on paths with no observable side effects. resolve_btfids then turns eligible, ftrace-reachable candidates into BTF declaration tags naming the function as an fmod_ret target and listing the exact negative values it may return on those clean paths.

When an fmod_ret program attaches to such a found target, the verifier requires every exit to return 0 or one of those tagged errors, so a synthetic failure still looks like a real one to callers. Programs under that regime cannot use tail calls, and freplace extensions cannot swap them for something that returns arbitrary values. Targets that still come from static rules or explicit BTF_FMODRET sets keep today’s unrestricted behaviour. For long-returning functions, the series also forces JIT compilation, because the interpreter would truncate a valid 64-bit error into a non-error that still skips the original call.

bpftool gains fmodret list and show commands to dump tagged targets from vmlinux and loaded modules, including sleepable eligibility and allowed return sets. Selftests enable the plugin under suitable clang builds and check tag generation and verifier policy end to end.

If merged, the work would widen fmod_ret coverage across the tree while keeping the safety model that returning an error must still mean a believable failure.