docs(bpf/net): document why the socket-hook deny tails are intentionally not de-duped#210
Merged
Conversation
…uped Re-attempting the net-hook tail de-dup (the reverted PR #207) regresses BPF-LSM load of all 6 socket_* hooks on kernels 6.8 and 6.12 -- reproduced on the cross-kernel bpfcompat matrix across three independent implementations (__always_inline helper, function-like macro, macro minus the ipv6 branch). The unified-tail instruction layout is rejected by the 6.8/6.12 verifiers at bpf_prog_load (-EINVAL, func_info/line_info BTF validation, no verifier-log output) while 5.15/6.1/6.17 accept it -- verifier acceptance is non-monotonic across versions, and the hand-written per-hook tails are the layout that loads everywhere. A real __noinline subprogram is impossible (emit needs 14 args > BPF's 5-register call limit). The de-dup buys only line count, zero behavior change. Document the constraint in-code so it is not re-attempted; the matrix gate (PR #209) catches any load regression pre-merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Re-attempted the network-hook tail de-dup (the reverted #207) the right way this time: diagnosed the
-22root cause on real 6.8/6.12 kernels via the cross-kernel bpfcompat matrix before touchingmain. The evidence is a clean negative result — the de-dup cannot be landed without regressing BPF-LSM load on two LTS kernels, for zero behavioral benefit. This PR records that finding in-code so it isn't attempted a fourth time.What was proven (on real 6.8 + 6.12 kernels)
All 6
socket_*hooks fail to load (0/6) under every viable de-dup form, vs 6/6 for the hand-written tails:__always_inlinehelperRuled out: complexity/instruction limit (the de-dup is smaller — 6937 vs 8685 insns), helper-function BTF metadata (no
emit_net_block_eventFUNC even in the broken object — clang inlined it), outlined BPF-to-BPF subprogram (22 FUNCs in all variants), the ipv6 maybe-NULL pointer.Cause: load-time
-EINVALwith no verifier output even atlog_level=1→ the kernel'sfunc_info/line_infoBTF validation rejecting the unified tail's instruction layout on 6.8/6.12, which 5.15/6.1/6.17 accept. Verifier acceptance is non-monotonic across versions. A real__noinlinesubprogram is structurally impossible (emit needs 14 args > BPF's 5-register call limit).Change
A 22-line
INTENTIONAL DUPLICATIONcomment at the net hooks. No code/behavior change. This PR also exercises the bpfcompat matrix gate (#209) — which should pass 5/5, proving the hooks still load everywhere.🤖 Generated with Claude Code