Message ID | 20240725-convert_dev_cgroup-v1-0-2c8cbd487c44@bootlin.com (mailing list archive) |
---|---|
Headers | show |
Series | selftests/bpf: convert test_dev_cgroup to test_progs | expand |
On 07/25, Alexis Lothoré (eBPF Foundation) wrote: > Hello, > this small series aims to integrate test_dev_cgroup in test_progs so it > could be run automatically in CI. The new version brings a few differences > with the current one: > - test now uses directly syscalls instead of wrapping commandline tools > into system() calls > - test_progs manipulates /dev/null (eg: redirecting test logs into it), so > disabling access to it in the bpf program confuses the tests. To fix this, > the first commit modifies the bpf program to allow access to char devices > 1:3 (/dev/null), and disable access to char devices 1:5 (/dev/zero) > - once test is converted, add a small subtest to also check for device type > interpretation (char or block) > - paths used in mknod tests are now in /dev instead of /tmp: due to the CI > runner organisation and mountpoints manipulations, trying to create nodes > in /tmp leads to errors unrelated to the test (ie, mknod calls refused by > kernel, not the bpf program). I don't understand exactly the root cause > at the deepest point (all I see in CI is an -ENXIO error on mknod when trying to > create the node in tmp, and I can not make sense out of it neither > replicate it locally), so I would gladly take inputs from anyone more > educated than me about this. > > The new test_progs part has been tested in a local qemu environment as well > as in upstream CI: > > ./test_progs -a cgroup_dev > 47/1 cgroup_dev/deny-mknod:OK > 47/2 cgroup_dev/allow-mknod:OK > 47/3 cgroup_dev/deny-mknod-wrong-type:OK > 47/4 cgroup_dev/allow-read:OK > 47/5 cgroup_dev/allow-write:OK > 47/6 cgroup_dev/deny-read:OK > 47/7 cgroup_dev/deny-write:OK > 47 cgroup_dev:OK > Summary: 1/7 PASSED, 0 SKIPPED, 0 FAILED > > --- > Alexis Lothoré (eBPF Foundation) (3): > selftests/bpf: do not disable /dev/null device access in cgroup dev test > selftests/bpf: convert test_dev_cgroup to test_progs > selftests/bpf: add wrong type test to cgroup dev > > tools/testing/selftests/bpf/.gitignore | 1 - > tools/testing/selftests/bpf/Makefile | 2 - > .../testing/selftests/bpf/prog_tests/cgroup_dev.c | 123 +++++++++++++++++++++ > tools/testing/selftests/bpf/progs/dev_cgroup.c | 4 +- > tools/testing/selftests/bpf/test_dev_cgroup.c | 85 -------------- > 5 files changed, 125 insertions(+), 90 deletions(-) > --- > base-commit: c90e2d4a7738a24fbb3657092dbd1ca20c040ed1 > change-id: 20240723-convert_dev_cgroup-6464b0d37f1a > > Best regards, > -- > Alexis Lothoré, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > Going forward, can you pls use [PATCH bpf-next] as a subject (or bpf when targeting bpf tree)? I'm not sure whether patchworks picks up plain [PATCH] messages..
On 7/27/24 00:49, Stanislav Fomichev wrote: > On 07/25, Alexis Lothoré (eBPF Foundation) wrote: >> Hello, >> this small series aims to integrate test_dev_cgroup in test_progs so it >> could be run automatically in CI. The new version brings a few differences >> with the current one: >> - test now uses directly syscalls instead of wrapping commandline tools >> into system() calls >> - test_progs manipulates /dev/null (eg: redirecting test logs into it), so >> disabling access to it in the bpf program confuses the tests. To fix this, >> the first commit modifies the bpf program to allow access to char devices >> 1:3 (/dev/null), and disable access to char devices 1:5 (/dev/zero) >> - once test is converted, add a small subtest to also check for device type >> interpretation (char or block) >> - paths used in mknod tests are now in /dev instead of /tmp: due to the CI >> runner organisation and mountpoints manipulations, trying to create nodes >> in /tmp leads to errors unrelated to the test (ie, mknod calls refused by >> kernel, not the bpf program). I don't understand exactly the root cause >> at the deepest point (all I see in CI is an -ENXIO error on mknod when trying to >> create the node in tmp, and I can not make sense out of it neither >> replicate it locally), so I would gladly take inputs from anyone more >> educated than me about this. >> [...] > Going forward, can you pls use [PATCH bpf-next] as a subject (or bpf when > targeting bpf tree)? I'm not sure whether patchworks picks up > plain [PATCH] messages.. Yes, my bad, I realized some time after sending that I may have missed some proper patch prefix. I have just checked on patchwork and see this series and the one I have sent before, so I guess there is no need to resend those, but I'll make sure to apply the relevant prefix for next series. Thanks, Alexis