On 12/18, Alexei Starovoitov wrote:

On Mon, Dec 17, 2018 at 10:25:48AM -0800, Stanislav Fomichev wrote:

quoted

If test_maps/test_verifier is running against the kernel which doesn't
have _all_ BPF features enabled, it fails with an error. This patch
series tries to probe kernel support for each failed test and skip
it instead. This lets users run BPF selftests in the not-all-bpf-yes
environments and received correct PASS/NON-PASS result.

See https://www.spinics.net/lists/netdev/msg539331.html for more
context.

The series goes like this:

* patch #1 adds bpf_prog_type_supported() and
  bpf_map_type_supported() which query the kernel (insert 'return 0'
  program or try to create empty map with correct key/value sizes) and
  return supported/unsupported.
  Note: this functionality can later be reimplemented on top of Quentin's
  recent 'bpftool feature' patchset if he decides to move the probes
  into libbpf.
* patch #2 skips sockmap tests in test_maps.c if BPF_MAP_TYPE_SOCKMAP
  map is not supported (if bpf_create_map fails, we probe the kernel
  for support)
* patch #3 skips verifier tests if test->prog_type is not supported (if
  bpf_verify_program fails, we probe the kernel for support)
* patch #4 skips verifier tests if test fixup map is not supported (if
  create_map fails, we probe the kernel for support)
  Note: we can probably move this probe into create_map helper and
  return some argument instead of adding skip_unsupported_map()
  to each fixup; but I'm not sure it's better.
  Also note: in current implementation we still print 'Failed to
  create hash map' from the create_map, but still skip the test.
* next patches fix various small issues that arise from the first four:
  * patch #5 sets "unknown func bpf_trace_printk#6" prog_type to
    BPF_PROG_TYPE_TRACEPOINT so it is correctly skipped in
    CONFIG_BPF_EVENTS=n case
  * patch #6 exposes BPF_PROG_TYPE_CGROUP_{SKB,SOCK,SOCK_ADDR} only when
    CONFIG_CGROUP_BPF=y, this makes verifier correctly skip appropriate
    tests

v2 changes:

* don't sprinkle "ifdef CONFIG_CGROUP_BPF" all around net/core/filter.c,
  doing it only in the bpf_types.h is enough to disable
  BPF_PROG_TYPE_CGROUP_{SKB,SOCK,SOCK_ADDR} prog types for non-cgroup
  enabled kernels

the patches look good to me.
I think it's ok to proceed this way though long term we probably
want to have such bpf_prog_type_supported() to be part of libbpf
and reused in test_verifier.c and in bpftool.

Quentin is working on adding more generic bpf_xyz_type_supported() to
libbpf. My plan is to switch to them as soon as they are merged.

Daniel, thoughts?