lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Jan 2020 22:26:57 +0100 From: Toke Høiland-Jørgensen <toke@...hat.com> To: Andrii Nakryiko <andrii.nakryiko@...il.com> Cc: Andrii Nakryiko <andriin@...com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org> Subject: Re: [PATCH bpf-next] libbpf: Fix include of bpf_helpers.h when libbpf is installed on system Andrii Nakryiko <andrii.nakryiko@...il.com> writes: > On Tue, Jan 14, 2020 at 11:07 AM Andrii Nakryiko > <andrii.nakryiko@...il.com> wrote: >> >> On Tue, Jan 14, 2020 at 8:43 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote: >> > >> > The change to use angled includes for bpf_helper_defs.h breaks compilation >> > against libbpf when it is installed in the include path, since the file is >> > installed in the bpf/ subdirectory of $INCLUDE_PATH. Fix this by adding the >> > bpf/ prefix to the #include directive. >> > >> > Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir") >> > Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com> >> > --- >> > Not actually sure this fix works for all the cases you originally tried to >> >> This does break selftests/bpf. Have you tried building selftests, does >> it work for you? We need to fix selftests simultaneously with this >> change. >> >> > fix with the referred commit; please check. Also, could we please stop breaking >> > libbpf builds? :) >> >> Which libbpf build is failing right now? Both github and in-kernel >> libbpf builds are fine. You must be referring to something else. What >> exactly? > > I think it's better to just ensure that when compiling BPF programs, > they have -I/usr/include/bpf specified, so that all BPF-side headers > can be simply included as #include <bpf_helpers.h>, #include > <bpf_tracing.h>, etc And break all programs that don't have that already? Just to make the kernel build env slightly more convenient? Hardly friendly to the library users, is it? :) As far as selftests are concerned, I finally managed to get an LLVM version that will build them all; so I'll test that tomorrow and send a v2 that doesn't break them... -Toke
Powered by blists - more mailing lists