netdev - Re: [PATCH bpf-next v2 11/15] selftests/xsk: get rid of built-in XDP program

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]

Message-ID: <CAEf4BzahRoqeKEHFfrJf0tZD3vzjm1jx1rdkfiyBj52uxVGW7g@mail.gmail.com>
Date:   Wed, 11 Jan 2023 11:20:03 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     Magnus Karlsson <magnus.karlsson@...il.com>,
        magnus.karlsson@...el.com, bjorn@...nel.org, ast@...nel.org,
        daniel@...earbox.net, netdev@...r.kernel.org,
        maciej.fijalkowski@...el.com, bpf@...r.kernel.org, yhs@...com,
        andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
        john.fastabend@...il.com, kpsingh@...nel.org, haoluo@...gle.com,
        jolsa@...nel.org, tirthendu.sarkar@...el.com,
        jonathan.lemon@...il.com
Subject: Re: [PATCH bpf-next v2 11/15] selftests/xsk: get rid of built-in XDP program

On Wed, Jan 4, 2023 at 3:44 PM Stanislav Fomichev <sdf@...gle.com> wrote:
>
> On Wed, Jan 4, 2023 at 3:15 PM Andrii Nakryiko
> <andrii.nakryiko@...il.com> wrote:
> >
> > On Wed, Jan 4, 2023 at 4:19 AM Magnus Karlsson
> > <magnus.karlsson@...il.com> wrote:
> > >
> > > From: Magnus Karlsson <magnus.karlsson@...el.com>
> > >
> > > Get rid of the built-in XDP program that was part of the old libbpf
> > > code in xsk.c and replace it with an eBPF program build using the
> > > framework by all the other bpf selftests. This will form the base for
> > > adding more programs in later commits.
> > >
> > > Signed-off-by: Magnus Karlsson <magnus.karlsson@...el.com>
> > > ---
> > >  tools/testing/selftests/bpf/Makefile          |  2 +-
> > >  .../selftests/bpf/progs/xsk_xdp_progs.c       | 19 ++++
> > >  tools/testing/selftests/bpf/xsk.c             | 88 ++++---------------
> > >  tools/testing/selftests/bpf/xsk.h             |  6 +-
> > >  tools/testing/selftests/bpf/xskxceiver.c      | 72 ++++++++-------
> > >  tools/testing/selftests/bpf/xskxceiver.h      |  7 +-
> > >  6 files changed, 88 insertions(+), 106 deletions(-)
> > >  create mode 100644 tools/testing/selftests/bpf/progs/xsk_xdp_progs.c
> > >
> > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> > > index 205e8c3c346a..a0193a8f9da6 100644
> > > --- a/tools/testing/selftests/bpf/Makefile
> > > +++ b/tools/testing/selftests/bpf/Makefile
> > > @@ -240,7 +240,7 @@ $(OUTPUT)/flow_dissector_load: $(TESTING_HELPERS)
> > >  $(OUTPUT)/test_maps: $(TESTING_HELPERS)
> > >  $(OUTPUT)/test_verifier: $(TESTING_HELPERS) $(CAP_HELPERS)
> > >  $(OUTPUT)/xsk.o: $(BPFOBJ)
> >
> > shouldn't $(OUTPUT)/xsk_xdp_progs.skel.h be added as a dependency
> > here, at .o file?
>
> Not sure we can:
> xsk.o is a 'generic' library and xsk_xdp_progs.skel.h is xskxceiver-specific.

Oh, I'm just not very familiar with xskxceiver. What I meant was that
this skel.h header should be a dependency of an object file that
results from .c file that includes that skel.h header. It seems like
it's a xskxceiver.c -> xskxceiver.o in this case, that's where I'd add
dependency.

But it might not be possible for some reason (as we compile
test_verifier straight from test_verifier.c, bypassing .o creation),
which I might be forgetting.

>
> I was trying to see how it works for the other cases where we depend
> on the headers and saw the following:
>
> $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
>         $(call msg,BINARY,,$@)
>         $(Q)$(CC) $(CFLAGS) $(filter %.a %.o %.c,$^) $(LDLIBS) -o $@
>
> So at least for test_verifier, we explicitly filter out anything
> non-.[aoc]. Presumably because of the same issue?
> Should we do the same for xskxceiver? I've sent similar changes for my
> xdp_hw_metadata binary about an hour ago..

We do filter "irrelevant" inputs yes, as a general rule. And we can do
that for other binaries as well, yep.

>
> > > -$(OUTPUT)/xskxceiver: $(OUTPUT)/xsk.o
> > > +$(OUTPUT)/xskxceiver: $(OUTPUT)/xsk.o $(OUTPUT)/xsk_xdp_progs.skel.h
> >
> > and not here. Is that why we have this clang compilation failure?
> >
> > >
> > >  BPFTOOL ?= $(DEFAULT_BPFTOOL)
> > >  $(DEFAULT_BPFTOOL): $(wildcard $(BPFTOOLDIR)/*.[ch] $(BPFTOOLDIR)/Makefile)    \
> >
> > [...]