On Fri, Jan 10, 2025 at 7:58 AM Ihor Solodrai <ihor.solodrai@xxxxx> wrote: > > On Friday, January 10th, 2025 at 5:51 AM, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > > > > > > On Fri, Jan 10, 2025 at 02:31:41AM +0000, Ihor Solodrai wrote: > > > > > BPF CI caught a segfault on aarch64 and s390x [1] after recent merges > > > into the master branch. > > > > > > In the past the libbpf github actions was tracking the tmp.master (it would > > be better to track "next") branch and I was looking at when it passed to > > then move "next" to master, that would be great to have so that we > > wouldn't be having these bugs in the git history, avoiding force pushes. > > libbpf CI is still tracking tmp.master: > > https://github.com/libbpf/libbpf/actions/runs/12696027660/job/35389206487 > > However it only runs once a day. BPF CI runs more frequently due to the > volume of incoming patches. As of recently, BPF CI has been using "master". > Yesterday, when I saw the failures, I switched BPF CI to v1.28. > > I think the right way to approach this is for libbpf/libbpf to track "next", > and BPF CI use "master". Then, most importantly, only merge next into master > after libbpf CI has passed. > > This can potentially be automated, but would require push access to the > pahole repo. Until then, a maintainer would need to manually check the > libbpf CI status here: > > https://github.com/libbpf/libbpf/actions/workflows/test.yml > > Another thing is that libbpf CI only tests x86_64 currently. > We could add aarch64 to libbpf, or migrate pahole staging job to > kernel-patches/vmtest (which is almost identical to BPF CI). > > Andrii, what do you think? > It would be nice to test pahole as soon as any relevant libbpf patch is sent upstream for review. We should make sure this doesn't happen for all combinations of compiler/arch/etc, just pick one configuration for x86-64 and aarch64 and run that? [...]
