[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <62dcbdd6-c648-40a5-8346-3a290d8d0020@bootlin.com>
Date: Sat, 27 Jul 2024 10:01:51 +0200
From: Alexis Lothoré <alexis.lothore@...tlin.com>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
<eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>,
ebpf@...uxfoundation.org, Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
bpf@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] selftests/bpf: convert test_dev_cgroup to test_progs
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
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists