Gcc 16 switch and re-enable - #505
Conversation
8c192e9 to
0fd09ad
Compare
|
@vineetgarc are you still working on this? The gcc-bpf job is red, the PR doesn't look ready for review. |
There was a problem hiding this comment.
For the next respin, please use nice PR title and add a brief summary too. I now see that it depends on libbpf/ci#228, would be nice to mention that.
To submit a new revision you can just force push updated gcc-16-switch-n-fix-pathname branch, PR will be refreshed. Don't close and re-open the PR, it's harder to track the comments then.
Could you please also delete a commented block in matrix.py? With this PR it's stale (uncommenting won't work).
Yes I'm. This was gated on the libbpf-ci 228 which you pulled. Let me see what other changes you requeted and respin with better PR look and feel. Thx. |
77eebc3 to
25eafb4
Compare
|
@theihor fwiw this series has been proven to pass: cfr https://github.com/kernel-patches/vmtest/actions/runs/31639638784 |
|
@vineetgarc A couple of things to address:
For testing, add a commit on top that renames I don't want to move the tag right now, because CI is busy due to recent pushes to bpf and bpf-next. I expect tomorrow to be quieter. Thanks. |
25eafb4 to
61b3e41
Compare
Indeed it is flaky in my local runs: added now.
Done.
Oops done now. !
I think the prereq it wants is there. The 2nd one is not really mandatory. I'll check anyways.
No rush. Thx ! |
The denylist has not been touched since the GCC BPF runner was disabled in January 2025, so it still describes what GCC 15 was failing back then. Rebuild it against GCC-16 of today, which leaves it a good deal shorter. A test is denied outright only when nothing in it passes, otherwise the failing subtests are named individually so that the rest of the test keeps running. Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
The GCC BPF workflow compiles test_progs-bpf_gcc and then throws it away, so it only ever checked that the selftests still build with GCC. Nothing runs them: the runner was disabled in f7504ae ("Disable test_progs-bpf_gcc") because too many tests were failing with GCC 15, and it has stayed off since. As evident in previous patch to denylist, GCC 16 is in much better shape, still fails a fair number of selftests, but few enough that the remainder is worth running rather than leaving untested. Split the workflow into a build job and a test job, in the same shape as test-progs-asan.yml. The build job keeps doing what it did and now packages test_progs-bpf_gcc as an artifact; the test job unpacks it over the selftests directory from the main build and runs it under vmtest. Keeping this in its own workflow rather than folding the GCC BPF build into kernel-build.yml is deliberate. Every test and veristat job depends on the root build job, so a break in the GCC BPF compiler download, in the scripts, or in the GCC selftests build would take out the whole matrix leg and the artifact it produces. Here it can only fail the GCC BPF jobs. The test job needs /dev/kvm, so kernel-build-test.yml now passes the test runners; the build job continues to pick its own builder image. Drop the commented out matrix.py entry that used to run test_progs-bpf_gcc. The tests run again, just not through the test matrix, so the note saying they are disabled is now actively misleading. Gate the test job on run_tests, the same flag the matrix test job uses, so that push events keep building test_progs-bpf_gcc without occupying a test runner to run it. Signed-off-by: Vineet Gupta <vineet.gupta@linux.dev>
61b3e41 to
618bc84
Compare
|
It's green, congrats! :) I noticed a bunch of errors like this in the logs: Is this a known issue? The test_progs reports PASS on everything, so maybe it's not a blocker for the CI changes. |
|
Woo hoo ! and in this process uncovered a legit x86 jit bug ! https://lore.kernel.org/bpf/20260814165557.3405518-1-vineet.gupta@linux.dev/T/#u |
2 participants
This re-enables GCC built selftests - uses latest GCC (16 as of now)