Message ID | 20240731-convert_dev_cgroup-v4-0-849425d90de6@bootlin.com (mailing list archive) |
---|---|
Headers | show |
Series | selftests/bpf: convert test_dev_cgroup to test_progs | expand |
Hello: This series was applied to bpf/bpf-next.git (master) by Martin KaFai Lau <martin.lau@kernel.org>: On Wed, 31 Jul 2024 08:37:24 +0200 you 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. > > [...] Here is the summary with links: - [bpf-next,v4,1/3] selftests/bpf: do not disable /dev/null device access in cgroup dev test https://git.kernel.org/bpf/bpf-next/c/ba6a9018502e - [bpf-next,v4,2/3] selftests/bpf: convert test_dev_cgroup to test_progs https://git.kernel.org/bpf/bpf-next/c/d83d8230e415 - [bpf-next,v4,3/3] selftests/bpf: add wrong type test to cgroup dev https://git.kernel.org/bpf/bpf-next/c/84cdbff4a935 You are awesome, thank you!
On 7/31/24 20:40, patchwork-bot+netdevbpf@kernel.org wrote: > Hello: > > This series was applied to bpf/bpf-next.git (master) > by Martin KaFai Lau <martin.lau@kernel.org>: > > On Wed, 31 Jul 2024 08:37:24 +0200 you 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. >> >> [...] > > Here is the summary with links: > - [bpf-next,v4,1/3] selftests/bpf: do not disable /dev/null device access in cgroup dev test > https://git.kernel.org/bpf/bpf-next/c/ba6a9018502e > - [bpf-next,v4,2/3] selftests/bpf: convert test_dev_cgroup to test_progs > https://git.kernel.org/bpf/bpf-next/c/d83d8230e415 > - [bpf-next,v4,3/3] selftests/bpf: add wrong type test to cgroup dev > https://git.kernel.org/bpf/bpf-next/c/84cdbff4a935 > > You are awesome, thank you! For the record, I am not receiving the notification about my patches being merged (well, I receive it at least thanks to the mailing list, but not as the author). I see that my email address looks pretty broken in the recipient field. Could patchwork automation be confused by "customized" identity ?