Re: [PATCH bpf-next v4 0/3] selftests/bpf: convert test_dev_cgroup to test_progs

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 ?