feat(validator): set program type when libbpf can't infer it (auto-type + manifest override)#40
Merged
Merged
Conversation
…name When a program is left BPF_PROG_TYPE_UNSPEC after open because its ELF section name isn't one libbpf recognizes, set the type the artifact's own loader assigns, before load. Today this covers socket-filter programs in "socket"-prefixed sections (e.g. Inspektor Gadget's socket1), which otherwise fail with "missing BPF prog type". Reported per program in the run notes. Verified against IG trace_dns: the socket1 program-type error is gone (it is auto-typed to SOCKET_FILTER). trace_dns then surfaces a separate, deeper issue — a CO-RE relocation against IG's socket-enricher API type gadget_socket_value, which the IG loader supplies at runtime; that is a framework dependency, not a kernel-compat gap, and out of scope here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ErenAri
changed the title
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.
What
Make the validator set a program's BPF type when libbpf can't infer it from the ELF section name. Two layers:
BPF_PROG_TYPE_UNSPECafter open whose section is a recognizable family gets typed automatically. Today:socket-prefixed sections →SOCKET_FILTER(Inspektor Gadget'ssocket1).program_types:entries set any program's type explicitly:--set-prog-type <program|section>=<type>; applied before auto-typing (an explicit override wins). Supported types: socket_filter, kprobe, tracepoint, raw_tracepoint, xdp, perf_event, cgroup_skb, cgroup_sock, sched_cls, sched_act, sk_skb, sk_msg, tracing, lsm.Both are reported per program/override in the run notes.
Why
From the Inspektor Gadget thread (Alban Crequy):
trace_dns's program lives in asocket1section libbpf can't map to a type, so a generic load fails on every kernel withmissing BPF prog type. IG's loader setsSOCKET_FILTERitself; this does the same.Verification (real IG gadget, on the box)
bpfcompat test --artifact ghcr.io/inspektor-gadget/gadget/trace_dns:latest --quick→ thesocket1program-type error is gone (auto-typed program "ig_trace_dns" (section "socket1")).program_types:manifest → note showsprogram type override applied: "socket1"(and it takes precedence over auto-typing, as designed).trace_dnsthen advances to a separate, deeper issue — a CO-RE relocation againststruct gadget_socket_value(IG's socket-enricher API, BTF injected by the IG runtime). It fails identically on 6.1 and 6.8 → a framework dependency, not a kernel-compat gap, and the honest boundary of standalone gadget validation. Documented indocs/case-study-inspektor-gadget.md.Tests: manifest validation + CLI-arg construction added;
go build,go vet,gofmt,go test ./...clean; validator C compiles clean.🤖 Generated with Claude Code