-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Set runtime configuration in verifier tests #39143
Copy link
Copy link
Labels
area/datapathImpacts bpf/ or low-level forwarding details, including map management and monitor messages.Impacts bpf/ or low-level forwarding details, including map management and monitor messages.area/loaderImpacts the loading of BPF programs into the kernel.Impacts the loading of BPF programs into the kernel.pinnedThese issues are not marked stale by our issue bot.These issues are not marked stale by our issue bot.
Milestone
Metadata
Metadata
Assignees
Labels
area/datapathImpacts bpf/ or low-level forwarding details, including map management and monitor messages.Impacts bpf/ or low-level forwarding details, including map management and monitor messages.area/loaderImpacts the loading of BPF programs into the kernel.Impacts the loading of BPF programs into the kernel.pinnedThese issues are not marked stale by our issue bot.These issues are not marked stale by our issue bot.
Currently, there's no way of populating runtime configuration variables declared using
DECLARE_CONFIGin verifier tests. This prevents porting over macros likeENABLE_IPV4=1since they control branching, and the whole point of the verifier tests is having these chunks of code enabled.This issue is for coming up with and implementing a solution to replace the configuration values in the files in
bpf/complexity-tests/*/*/{1,2,etc}.txtwith another mechanism. There's an opportunity to innovate on our approach, automate testing to reduce oversights, potentially increasing verifier test coverage in the process.For example, given an ELF (bpf_lxc.o) and its config (struct BPFLXC), we could automatically generate all permutations of possible config values (true|false for bools, 0|1|MaxUint16 for u16, etc.) to ensure there can be no verifier errors under certain user configurations. Not sure how this will shake out in practice, but having some form of automation is now possible thanks to config structs.
Initially, a 1:1 port of the existing approach would suffice.