Re: Re: lsm_cgroup.c selftest fails to compile when CONFIG_PACKET!=y

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 19, 2024 at 3:35 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Fri, Jan 19, 2024 at 3:13 PM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
> >
> > On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov
> > <alexei.starovoitov@xxxxxxxxx> wrote:
> > >
> > > On Fri, Jan 19, 2024 at 7:00 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
> > > >
> > > > On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
> > > > >
> > > > > On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > Final goal would be have BPF selftests compiled and test against our own
> > > > > > kernel, without having to come up with a specific kernel flavor that is
> > > > > > used to build and run the selftest. For v5.14 and v5.19-based kernel it
> > > > > > works: compilation is successful and I was able to run the verifier
> > > > > > tests. (Did not try running the other tests though)
> > > > >
> > > > > You mean ./test_verifier binary, right?
> > > > > A lot of tests had been moved from ./test_verifier to ./test_progs since.
> > > > >
> > > > > > > As far as I understand, selftests are supposed to be built and run
> > > > > > > using specific configuration, here is how config for x86 CI is prepared:
> > > > > > >
> > > > > > > ./scripts/kconfig/merge_config.sh \
> > > > > > >          ./tools/testing/selftests/bpf/config \
> > > > > > >          ./tools/testing/selftests/bpf/config.vm \
> > > > > > >          ./tools/testing/selftests/bpf/config.x86_64
> > > > > > >
> > > > > > > (root is kernel source).
> > > > > > > I'm not sure if other configurations are supposed to be supported.
> > > > > >
> > > > > > Would it make sense to have makefile target that builds/runs a smaller
> > > > > > subset of general, config-agnostic selftests that tests the core feature
> > > > > > (e.g. verifier + instruction set)?
> > > > >
> > > > > In ideal world I'd say that ./test_progs should include/exclude tests
> > > > > conditioned on current configuration, but I don't know how much work
> > > > > would it be to adapt build system for this.
> > > > >
> > > >
> > > > I would also suggest skipping building the specific bpf test code when
> > > > a specific CONFIG is removed, sometimes
> > > > I only want to test some bpf selftests code I am interested in :)
> > >
> > > I don't think we should be complicating bpf selftests to test
> > > configurations with reduced kconfig.
> > > bpf/config.* is what we target in bpf CI and we expect
> > > developers do the same amount of testing before they send patches.
> >
> > Totally understand that from the kernel bpf developer perspective. I
> > am a bpf user learning how to write a bpf program from selftests, but
> > I guess there is another way to learn,  selftests is not for teaching
> > bpf users, no need to complicate.
>
> Try libbpf-bootstrap ([0]) as a simple setup to play with new BPF
> features. minimal or bootstrap examples are usually good starting
> points.
>
>   [0] https://github.com/libbpf/libbpf-bootstrap

Thanks! I am aware of libbpf-bootstrap, I am on an old centos 8 distro
which often miss linux headers that some selftests happens to require,
especially the ones that are not using vmlinux.h, when a bpf kernel
developer submit patches and selftests that I am interested in, I want
to run that selftests and learn the new feature, and then probably
port the new useful selftests code to a real use case bpf program. I
often run into other selftests compiling errors when I want to
selftest the new feature I am interested in. Anyway, it is my build
environment problem, not selftests.





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux