I upgrade to Fedora 31 yesterday and now I cannot build anymore with libbpf. Packages: kernel-headers-5.3.6-300.fc31.x86_64 libbpf-0.0.5-1.fc31.x86_64 Test: tredaell@aldebaran ~ 🎩echo "#include <bpf/xsk.h>" | gcc -x c - In file included from <stdin>:1: /usr/include/bpf/xsk.h: In function ‘xsk_ring_prod__needs_wakeup’: /usr/include/bpf/xsk.h:82:21: error: ‘XDP_RING_NEED_WAKEUP’ undeclared (first use in this function) 82 | return *r->flags & XDP_RING_NEED_WAKEUP; | ^~~~~~~~~~~~~~~~~~~~ /usr/include/bpf/xsk.h:82:21: note: each undeclared identifier is reported only once for each function it appears in /usr/include/bpf/xsk.h: In function ‘xsk_umem__extract_addr’: /usr/include/bpf/xsk.h:173:16: error: ‘XSK_UNALIGNED_BUF_ADDR_MASK’ undeclared (first use in this function) 173 | return addr & XSK_UNALIGNED_BUF_ADDR_MASK; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/bpf/xsk.h: In function ‘xsk_umem__extract_offset’: /usr/include/bpf/xsk.h:178:17: error: ‘XSK_UNALIGNED_BUF_OFFSET_SHIFT’ undeclared (first use in this function) 178 | return addr >> XSK_UNALIGNED_BUF_OFFSET_SHIFT; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tredaell@aldebaran ~ 🎩 XDP_RING_NEED_WAKEUP is defined in kernel v5.4-rc1 (77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10). XSK_UNALIGNED_BUF_ADDR_MASK and XSK_UNALIGNED_BUF_OFFSET_SHIFT are defined in kernel v5.4-rc1 (c05cd3645814724bdeb32a2b4d953b12bdea5f8c). I suggest to downgrade libbpf until kernel 5.4 is released on Fedora 31 (or until the needed commits are backported on Fedora 31)
what if we include uapi headers in libbpf-devel package? library is backward compatible with older kernels, so there should be no issue jirka
The official position of upstream is that new libbpf versions should work on old kernels, so I'll see if we can't get this fixed as a compatibility issue upstream... Pinged Magnus about it here: https://lore.kernel.org/netdev/87tv7qpdbt.fsf@toke.dk/T/#t
We should not make libbpf available until the corresponding upstream kernel is released. The API is not stable until then. It means libbpf based on kernel v5.4 should not be made available in Fedora until the kernel v5.4 is released; otherwise, we risk compatibility issues.
Note that I'm talking about *upstream* kernel v5.4 release. If the upstream github libbpf project tagged a code based on a -rc kernel version, they did it wrong and we'll need to get in a conversation with them. This is exactly what we discussed at LPC with them and with Alexei: libbpf should be tagging releases only after the corresponding upstream kernel is released.
libbpf upstream generally doesn't do bugfixes during the -rc phase: https://lore.kernel.org/bpf/20191016034222.zykzlaoinhjvrkef@ast-mbp/ dunno how we are going to handle this with respect to bug fixes... we may need to manually cherry-pick those if we follow the symbol version numbering in the package version?
That's very different to what we were discussing at LPC but I'm not surprised, we've seen that many times already. Given that libbpf is developed in the kernel and any kernel maintainer in the whole chain up to Linus can override anything and revert or apply any patch including libbpf one, it's not safe for us to use anything that's not a part of a released kernel. If the github libbpf repo is not adhering to that, we should probably base the libbpf package on the kernel source tree.
That's not going to be enough, though... We still won't get any bug fixes that way. For instance, there are a couple of backwards compatibility fixes that have gone into bpf-next now which won't be part of the final 5.4 release, even though they fix an issue that will prevent a 5.4 libbpf to work with a 5.3 kernel... That particular bug is probably not too relevant if we keep kernel and libbpf in lockstep, but the same goes for any other bugfix that may be.
Upstream fixes should not be applied to *-next. If this is what bpf maintainers are going, we need to raise that upstream, potentially involving higher level maintainers in the discussion.
Yeah, I guess we will. But we can deal with that down the line; for now, I think you are right that the right way to deal with this is to package libbpf from the kernel sources instead of the github repo...
FEDORA-2019-a91df4bfbc has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a91df4bfbc
FEDORA-2019-af39d9b211 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af39d9b211
libbpf-0.0.3-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a91df4bfbc
libbpf-0.0.3-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-af39d9b211
libbpf-0.0.3-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
libbpf-0.0.3-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.