netdev - Re: [PATCH v2 bpf-next] libbpf: always specify expected_attach

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 14 Apr 2020 12:38:13 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Andrey Ignatov <rdna@...com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next] libbpf: always specify expected_attach_type
 on program load if supported

On Tue, Apr 14, 2020 at 11:44 AM Andrey Ignatov <rdna@...com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@...il.com> [Tue, 2020-04-14 11:25 -0700]:
> > On Tue, Apr 14, 2020 at 10:56 AM Andrey Ignatov <rdna@...com> wrote:
> > >
> > > Andrii Nakryiko <andriin@...com> [Mon, 2020-04-13 21:56 -0700]:
>
> ...
>
> > > > v1->v2:
> > > > - fixed prog_type/expected_attach_type combo (Andrey);
> > > > - added comment explaining what we are doing in probe_exp_attach_type (Andrey).
> > >
> > > Thanks for changes.
> > >
> > > I built the patch (removing the double .sec Song mentioned since it
> > > breaks compilation) and tested it: it fixes the problem with NET_XMIT_CN
> >
> > Wait, what? How does it break compilation? I compiled and tested
> > before submitting and just cleaned and built again, no compilation
> > errors or even warnings. Can you share compilation error you got,
> > please?
>
> Sure:
>
>         11:37:28 1 rdna@...082.prn2:~/bpf-next$>/home/rdna/bin/clang --version
>         clang version 9.0.20190721
>         Target: x86_64-unknown-linux-gnu
>         Thread model: posix
>         InstalledDir: /home/rdna/bin
>         11:37:32 0 rdna@...082.prn2:~/bpf-next$>env GCC=~/bin/gcc CLANG=~/bin/clang CC=~/bin/clang LLC=~/bin/llc LLVM_STRIP=~/bin/llvm-strip  make V=1 -C tools/bpf/bpftool/

[...]

>
>         fatal error: too many errors emitted, stopping now [-ferror-limit=]
>         20 errors generated.
>            ld -r -o staticobjs/libbpf-in.o  staticobjs/libbpf.o staticobjs/bpf.o staticobjs/nlattr.o staticobjs/btf.o staticobjs/libbpf_errno.o staticobjs/str_error.o staticobjs/netlink.o staticobjs/bpf_prog_linfo.o staticobjs/libbpf_probes.o staticobjs/xsk.o staticobjs/hashmap.o staticobjs/btf_dump.o
>         ld: cannot find staticobjs/libbpf.o: No such file or directory
>         make[2]: *** [staticobjs/libbpf-in.o] Error 1
>         make[1]: *** [staticobjs/libbpf-in.o] Error 2
>         make[1]: Leaving directory `/home/rdna/bpf-next/tools/lib/bpf'
>         make: *** [/home/rdna/bpf-next/tools/lib/bpf/libbpf.a] Error 2
>         make: Leaving directory `/home/rdna/bpf-next/tools/bpf/bpftool'
>         11:37:43 2 rdna@...082.prn2:~/bpf-next$>

Weird, I can't repro it locally neither with GCC, nor with clang-9 or
latest clang...

>
> > > I guess we can deal with selftest separately in the original thread.
> >
> > Sure, if this is going to be applied to bpf as a fix, I'd rather
> > follow-up with selftests separately.
>
> Sounds good.
>
> > > Also a question about bpf vs bpf-next: since this fixes real problem
> > > with loading cgroup skb programs, should it go to bpf tree instead?
> >
> > It will be up to maintainers, it's not so clear whether it's a new
> > feature or a bug fix.. I don't mind either way.
>
> Sounds good. Thanks.
>
> --
> Andrey Ignatov