Fix auto testing by adding the verifier testing mode as well, suppress deperacation warnings - #92
Merged
Merged
Conversation
c2de7da added -W ignore::DeprecationWarning to the 'test' target only, so 'make test-cov' and 'make test-verifier' still drown in warnings from the generated vmlinux.py. Also correct the test-verifier note: the suite does not run pytest under sudo, tests/framework/verifier.py shells out to 'sudo bpftool' itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
These three declared @section("sometag1"), which is not a section name libbpf can map to a program type: libbpf: failed to guess program type from ELF section 'sometag1' so they were rejected before the kernel verifier ever saw them. They generate IR and compile fine; only the section was wrong. Switch to tracepoint/syscalls/sys_enter_execve, matching the other tracepoint tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
test_config.toml could only declare a failure at the "ir" or "llc" level, and test_verifier.py dropped every declared-xfail case from the level-3 run outright. A program that generates IR and compiles cleanly but that the kernel verifier rejects therefore had no way to be declared: it was silently treated as must-pass at all three levels. Levels now form an ordered pipeline (ir < llc < verifier) and a declared level marks that level and every later one xfail, which is what the old ir-implies-llc special case was expressing. Level 3 runs every test file and reports declared failures as expected ones rather than skipping them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The map was declared as RingBuf, which is not an exported name -- the class is
RingBuffer. maps_pass has no processor registered under RingBuf, so it fell
through to the 'unknown map type, defaulting to HashMap' path and was emitted
as BPF_MAP_TYPE_HASH with no key or value size. The kernel rejected it:
libbpf: map 'mymap': found type = 1.
libbpf: map 'mymap': failed to create: -EINVAL
Nothing caught this earlier because the test framework compiles the file's AST
and never imports it, so the bogus 'from pythonbpf.maps import RingBuf' never
raised ImportError.
Using the real name also subjects the map to process_ringbuf_map's validation,
which max_entries=1024 does not survive: a ringbuf needs a power of two at
least as large as the page size. Raised to 4096. libbpf now reports
type = 27 with max_entries = 4096.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
process_bpf_map logged a warning and fell back to process_hash_map for any map
type it did not recognise. That turns a typo into an object file that compiles
cleanly, carries the wrong BPF_MAP_TYPE, skips the intended map type's
parameter validation entirely, and is only rejected once it reaches the kernel
-- as tests/passing_tests/ringbuf.py was, with 'failed to create: -EINVAL'.
A warning was not enough to surface it either: the test framework only fails a
test on logging.ERROR records.
Raise instead, naming the registered map types so the fix is obvious:
ValueError: Unknown map type 'RingBuf' returned by 'm'.
Known map types: HashMap, PerfEventArray, RingBuffer
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It generates IR, compiles, and now passes the kernel verifier, so it is no longer a failing test. It sat in failing_tests/ with no test_config.toml entry, which meant the framework already required it to pass at every level -- the directory was merely misleading. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It generates IR and compiles, and the CO-RE relocations against struct xdp_md
resolve correctly, so it must keep passing levels 1 and 2. The kernel rejects
it: the 'data + 34 < data_end' guard is emitted as a signed compare over values
round-tripped through the stack, so the verifier never narrows the packet range
and the later iph.saddr read fails with
invalid access to packet, off=26 size=4, R1(id=0,off=26,r=0)
R1 offset is outside of the packet
Direct packet access needs bounds checks in a form the verifier can follow.
strict = True, so this flags up if that ever lands.
Co-Authored-By: Claude Opus 5 (1M context) <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.
No description provided.