On Thursday, January 16th, 2025 at 3:58 PM, Jose E. Marchesi <jose.march...@oracle.com> wrote:
> > [...] > > > > > > Effective BPF selftests denylist for GCC BPF is located here: > > > https://github.com/kernel-patches/vmtest/blob/master/ci/vmtest/configs/DENYLIST.test_progs-bpf_gcc > > > > The announcement triggered an off-list discussion among BPF devs about > > how to handle the test running, given the long denylist. > > > > The problem is that any new test is now a potential subject to > > debugging whether the test needs changes, or GCC doesn't work for it. > > > > As of now, an important missing piece on GCC side is the decl_tags > > support, as they are heavily used by BPF selftests. See a message from > > Yonghong Song: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673841.html > > > > Some discussed suggestions: > > * Run test_progs-bpf_gcc with "allowed to fail", so that the > > pipeline is never blocked > > * Only run GCC BPF compilation, and don't execute the tests > > > I think that this is the best solution for now, and the most useful. > > As soon as we achieve passing all the selftests (hopefully soon) then we > can change the CI to flag regressions on test run failures as well. Ok. I disabled the execution of the test_progs-bpf_gcc test runner for now. I think we should check on the state of the tests again after decl_tags support is landed. Thanks. > > > * Flip denylist to allowlist to prevent regressions, but not force > > new tests to work with GCC > > > > Input from GCC devs will be much appreciated. > > > > Thanks. > > > > > When a patch is submitted to BPF, normally a corresponding PR for > > > kernel-patches/bpf github repo is automatically created to trigger a > > > BPF CI run for this change. PRs opened manually will do that too, and > > > this can be used to test patches before submission. > > > > > > Since the CI automatically pulls latest GCC snapshot, a change in GCC > > > can potentially cause CI failures unrelated to Linux changes being > > > tested. This is not the only dependency like that, of course. > > > > > > In such situations, a change is usually made in CI code to mitigate > > > the failure in order to unblock the pipeline for patches. If that > > > happens with GCC, someone (most likely me) will have to reach out to > > > GCC team. I guess gcc@gcc.gnu.org would be the default point of > > > contact, but if there are specific people who should be notified > > > please let me know.
