link: Allow kprobe multi to be disabled in kernel

[arthurfabre]

Kprobe multi support is gated on CONFIG_FPROBE, without it creating the link fails with ENOTSUP: https://elixir.bootlin.com/linux/latest/source/include/linux/fprobe.h#L56

Unfortunately the standard Debian sid kernel does not have it enabled.

Update the kprobe multi test to handle ENOTSUP, and drop the minimum kernel version check, tests otherwise fail with:

Feature 'bpf_link_kprobe_multi' isn't supported even though kernel v5.19.11 is newer than v5.18

[mmat11]

shouldn't the if err != nil check be left here?

[arthurfabre]

🤦 Yes, my bad. Good catch. Fixed.

[lmb]

Thanks! You're hitting this when trying to run the tests on your laptop?

[lmb]

I think this version number should stay, otherwise our CI will miss this test failing.

[arthurfabre]

If we don't remove the version number, tests fail for me with:

Feature 'bpf_link_kprobe_multi' isn't supported even though kernel v5.19.11 is newer than v5.18

Maybe we can add some magic (-X define or a build tag) so the version number checks happen in CI tests, but not locally? I can give it a go if that sounds sane.

[lmb]

Hmm, I'd like to keep the default (= when running locally) to throw an error when this happens. Otherwise developing a new feature test becomes cumbersome.

How about an environment variable that contains separated feature test names for which to ignore an error result? Basically, in

ebpf/internal/testutils/feature.go

Lines 58 to 62 in 8fceee5

	if ufe.MinimumVersion.Less(kernelVersion) {
	tb.Helper()
	tb.Fatalf("Feature '%s' isn't supported even though kernel %s is newer than %s",
	ufe.Name, kernelVersion, ufe.MinimumVersion)
	}

check tb.Name() against an env var and call tb.Skip(). Brownie points if we only split the env var once or so.

This means you have to opt in to ignore the result, but you can stick that variable in your .bashrc or something. If your kernel changes and the test automagically isn't skipped anymore.

[ti-mo]

I also think the version number should stay, Build tags are a hard nack from me, and ldflags are quite cumbersome to specify.

We've also recently adopted envs in cilium/cilium to gate test behaviours. All in all, I think it's the lesser evil, because they can be set ambiently and are easy to slap onto any command, as there might be arbitrary tools/scripts in between your shell and the actual test binaries reading the env.

I'd probably go with a single env here (like EBPF_TEST_IGNORE_KERNEL_VERSION?) that basically trusts the verdict of our haveBPFXYZ() functions and doesn't execute the kernel version check. We could add this kind of skip in testutils.CheckFeatureTest() or testutils.checkKernelVersion(), although the latter might cause more unintended side effects.

As long as the default doesn't change and we don't relax CI.

[arthurfabre]

Yup I'm hitting it locally on my laptop with the stock debian sid kernel (5.19.11 right now).

[lmb]

I've dropped the minimum version change, and used EOPNOTSUPP instead of ENOTSUP. Those are the same on my system but using EOPNOTSUPP is what the kernel uses, sticking to that should be less confusing.

lorenz@ubuntares:~$ errno EOPNOTSUPP
EOPNOTSUPP 95 Operation not supported
lorenz@ubuntares:~$ errno ENOTSUP
ENOTSUP 95 Operation not supported