On Thu, Sep 24, 2020 at 2:24 PM Toke Høiland-Jørgensen [off-list ref] wrote:

Andrii Nakryiko [off-list ref] writes:

quoted

On Thu, Sep 24, 2020 at 7:36 AM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

Alexei Starovoitov [off-list ref] writes:

quoted

On Tue, Sep 22, 2020 at 08:38:38PM +0200, Toke Høiland-Jørgensen wrote:

quoted

@@ -746,7 +748,9 @@ struct bpf_prog_aux {
     u32 max_rdonly_access;
     u32 max_rdwr_access;
     const struct bpf_ctx_arg_aux *ctx_arg_info;
-    struct bpf_prog *linked_prog;

This change breaks bpf_preload and selftests test_bpffs.
There is really no excuse not to run the selftests.

I did run the tests, and saw no more breakages after applying my patches
than before. Which didn't catch this, because this is the current state
of bpf-next selftests:

# ./test_progs  | grep FAIL
test_lookup_update:FAIL:map1_leak inner_map1 leaked!
#10/1 lookup_update:FAIL
#10 btf_map_in_map:FAIL

this failure suggests you are not running the latest kernel, btw

I did see that discussion (about the reverted patch), and figured that
was the case. So I did a 'git pull' just before testing, and still got
this.

$ git describe HEAD
v5.9-rc3-2681-g182bf3f3ddb6

so any other ideas? :)

That memory leak was fixed in 1d4e1eab456e ("bpf: Fix map leak in
HASH_OF_MAPS map") at the end of July. So while your git repo might be
checked out on a recent enough commit, could it be that the kernel
that you are running is not what you think you are running?

I specifically built kernel from the same commit and double-checked:

[vmuser@archvm bpf]$ uname -r
5.9.0-rc6-01779-g182bf3f3ddb6
[vmuser@archvm bpf]$ sudo ./test_progs -t map_in_map
#10/1 lookup_update:OK
#10/2 diff_size:OK
#10 btf_map_in_map:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED

quoted

quoted

configure_stack:FAIL:BPF load failed; run with -vv for more info
#72 sk_assign:FAIL

(and what about this one, now that I'm asking?)

Did you run with -vv? Jakub Sitnicki (cc'd) might probably help, if
you provide a bit more details.

quoted

quoted

test_test_bpffs:FAIL:bpffs test  failed 255
#96 test_bpffs:FAIL
Summary: 113/844 PASSED, 14 SKIPPED, 4 FAILED

The test_bpffs failure happens because the umh is missing from the
.config; and when I tried to fix this I ended up with:

yeah, seems like selftests/bpf/config needs to be updated to mention
UMH-related config values:

CONFIG_BPF_PRELOAD=y
CONFIG_BPF_PRELOAD_UMD=m|y

with that test_bpffs shouldn't fail on master

Yup, did get that far, and got the below...

quoted

quoted

[..]
  CC [M]  kernel/bpf/preload/bpf_preload_kern.o

Auto-detecting system features:
...                        libelf: [ OFF ]
...                          zlib: [ OFF ]
...                           bpf: [ OFF ]

No libelf found

might be worthwhile to look into why detection fails, might be
something with Makefiles or your environment

I think it's actually another instance of the bug I fixed with this
commit:

1eb832ac2dee ("tools/bpf: build: Make sure resolve_btfids cleans up after itself")

which I finally remembered after being tickled by the error message
seeming familiar. And indeed, manually removing the 'feature' directory
in kernel/bpf/preload seems to fix the issue, so I'm planning to go fix
that Makefile as well...

glad we got to the bottom of it

quoted

quoted

...which I just put down to random breakage, turned off the umh and
continued on my way (ignoring the failed test). Until you wrote this I
did not suspect this would be something I needed to pay attention to.
Now that you did mention it, I'll obviously go investigate some more, my
point is just that in this instance it's not accurate to assume I just
didn't run the tests... :)

Don't just assume some tests are always broken. Either ask or
investigate on your own. Such cases do happen from time to time while
we wait for a fix in bpf to get merged into bpf-next or vice versa,
but it's rare. We now have two different CI systems running selftests
all the time, in addition to running them locally as well, so any
permanent test failure is very apparent and annoying, so we fix them
quickly. So, when in doubt - ask or fix.

That's good to know; and I do think the situation has improved
immensely. There was a time when the selftests broke every other week
(or so it felt, at least), and I guess I'm still a bit scarred from
that.

One thing that would be really useful would be to have a 'reference
config' or something like that. Missing config options are a common
reason for test failures (as we have just seen above), and it's not
always obvious which option is missing for each test. Even something
like grepping .config for BPF doesn't catch everything. If you already
have a CI running, just pointing to that config would be a good start
(especially if it has history). In an ideal world I think it would be
great if each test could detect whether the kernel has the right config
set for its features and abort with a clear error message if it isn't...

so tools/testing/selftests/bpf/config is intended to list all the
config values necessary, but given we don't update them often we
forget to update them when selftests requiring extra kernel config are
added, unfortunately.

As for CI's config, check [0], that's what we use to build kernels.
Kernel config is intentionally pretty minimal and is running in a
single-user mode in pretty stripped down environment, so might not
work as is for full-blown VM. But you can still take a look.

  [0] https://github.com/libbpf/libbpf/blob/master/travis-ci/vmtest/configs/latest.config

quoted

quoted

quoted

I think I will just start marking patches as changes-requested when I see that
they break tests without replying and without reviewing.
Please respect reviewer's time.

That is completely fine if the tests are working in the first place. And

They are and hopefully moving forward that would be your assumption.

Sure, with the exception of the two tests still failing that I mentioned
above. Which I'm hoping you can help figure out the reason for :)

-Toke