On 4/1/24 5:34 AM, Muhammad Usama Anjum wrote:
> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
> dev_cgroup.skel.h and load program from it accourdingly.
>
> ./test_progs -t dev_cgroup
> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
> 64+0 records in
> 64+0 records out
> 32768 bytes (33 kB, 32 KiB) copied, 0.000856684 s, 38.2 MB/s
> dd: failed to open '/dev/full': Operation not permitted
> dd: failed to open '/dev/random': Operation not permitted
> #72 test_dev_cgroup:OK
> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
> Signed-off-by: Muhammad Usama Anjum <[email protected]>
> ---
> Changes since v2:
> - Replace test_dev_cgroup with serial_test_dev_cgroup as there is
> probability that the test is racing against another cgroup test
> - Minor changes to the commit message above
>
> I've tested the patch with vmtest.sh on bpf-next/for-next and linux
> next. It is passing on both. Not sure why it was failed on BPFCI.
> Test run with vmtest.h:
> sudo LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh ./test_progs -t dev_cgroup
> ./test_progs -t dev_cgroup
> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
> 64+0 records in
> 64+0 records out
> 32768 bytes (33 kB, 32 KiB) copied, 0.000403432 s, 81.2 MB/s
> dd: failed to open '/dev/full': Operation not permitted
> dd: failed to open '/dev/random': Operation not permitted
> #69 dev_cgroup:OK
> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
The CI failure:
Error: #72 dev_cgroup
serial_test_dev_cgroup:PASS:skel_open_and_load 0 nsec
serial_test_dev_cgroup:PASS:cgroup_setup_and_join 0 nsec
serial_test_dev_cgroup:PASS:bpf_attach 0 nsec
serial_test_dev_cgroup:PASS:bpf_query 0 nsec
serial_test_dev_cgroup:PASS:bpf_query 0 nsec
serial_test_dev_cgroup:PASS:rm 0 nsec
serial_test_dev_cgroup:PASS:mknod 0 nsec
serial_test_dev_cgroup:PASS:rm 0 nsec
serial_test_dev_cgroup:PASS:rm 0 nsec
serial_test_dev_cgroup:FAIL:mknod unexpected mknod: actual 256 !=
expected 0
serial_test_dev_cgroup:PASS:rm 0 nsec
serial_test_dev_cgroup:PASS:dd 0 nsec
serial_test_dev_cgroup:PASS:dd 0 nsec
serial_test_dev_cgroup:PASS:dd 0 nsec
(cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
The error code 256 means mknod execution has some issues. Maybe you need
to find specific errno to find out what is going on. I think you can do
ci on-demanding test to debug.
https://www.kernel.org/doc/Documentation/bpf/bpf_devel_QA.rst
>
> Changes since v1:
> - Rename file from test_dev_cgroup.c to dev_cgroup.c
> - Use ASSERT_* in-place of CHECK
> ---
> .../selftests/bpf/prog_tests/dev_cgroup.c | 58 +++++++++++++
> tools/testing/selftests/bpf/test_dev_cgroup.c | 85 -------------------
> 2 files changed, 58 insertions(+), 85 deletions(-)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/dev_cgroup.c
> delete mode 100644 tools/testing/selftests/bpf/test_dev_cgroup.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/dev_cgroup.c b/tools/testing/selftests/bpf/prog_tests/dev_cgroup.c
> new file mode 100644
> index 0000000000000..da0bc209d6a21
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/dev_cgroup.c
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2017 Facebook
> + */
> +
> +#include <test_progs.h>
> +#include <time.h>
> +#include "cgroup_helpers.h"
> +#include "dev_cgroup.skel.h"
> +
> +#define TEST_CGROUP "/test-bpf-based-device-cgroup/"
> +
> +void serial_test_dev_cgroup(void)
> +{
> + struct dev_cgroup *skel;
> + int cgroup_fd, err;
> + __u32 prog_cnt;
> +
> + skel = dev_cgroup__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "skel_open_and_load"))
> + goto cleanup;
> +
> + cgroup_fd = cgroup_setup_and_join(TEST_CGROUP);
> + if (!ASSERT_GT(cgroup_fd, 0, "cgroup_setup_and_join"))
> + goto cleanup;
> +
> + err = bpf_prog_attach(bpf_program__fd(skel->progs.bpf_prog1), cgroup_fd,
> + BPF_CGROUP_DEVICE, 0);
> + if (!ASSERT_EQ(err, 0, "bpf_attach"))
> + goto cleanup;
> +
> + err = bpf_prog_query(cgroup_fd, BPF_CGROUP_DEVICE, 0, NULL, NULL, &prog_cnt);
> + if (!ASSERT_EQ(err, 0, "bpf_query") || (!ASSERT_EQ(prog_cnt, 1, "bpf_query")))
> + goto cleanup;
> +
> + /* All operations with /dev/zero and /dev/urandom are allowed,
> + * everything else is forbidden.
> + */
> + ASSERT_EQ(system("rm -f /tmp/test_dev_cgroup_null"), 0, "rm");
> + ASSERT_NEQ(system("mknod /tmp/test_dev_cgroup_null c 1 3"), 0, "mknod");
> + ASSERT_EQ(system("rm -f /tmp/test_dev_cgroup_null"), 0, "rm");
> +
> + /* /dev/zero is whitelisted */
> + ASSERT_EQ(system("rm -f /tmp/test_dev_cgroup_zero"), 0, "rm");
> + ASSERT_EQ(system("mknod /tmp/test_dev_cgroup_zero c 1 5"), 0, "mknod");
> + ASSERT_EQ(system("rm -f /tmp/test_dev_cgroup_zero"), 0, "rm");
> +
> + ASSERT_EQ(system("dd if=/dev/urandom of=/dev/zero count=64"), 0, "dd");
> +
> + /* src is allowed, target is forbidden */
> + ASSERT_NEQ(system("dd if=/dev/urandom of=/dev/full count=64"), 0, "dd");
> +
> + /* src is forbidden, target is allowed */
> + ASSERT_NEQ(system("dd if=/dev/random of=/dev/zero count=64"), 0, "dd");
> +
> +cleanup:
> + cleanup_cgroup_environment();
> + dev_cgroup__destroy(skel);
> +}
> diff --git a/tools/testing/selftests/bpf/test_dev_cgroup.c b/tools/testing/selftests/bpf/test_dev_cgroup.c
> deleted file mode 100644
> index adeaf63cb6fa3..0000000000000
> --- a/tools/testing/selftests/bpf/test_dev_cgroup.c
> +++ /dev/null
> @@ -1,85 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/* Copyright (c) 2017 Facebook
> - */
> -
> -#include <stdio.h>
> -#include <stdlib.h>
> -#include <string.h>
> -#include <errno.h>
> -#include <assert.h>
> -#include <sys/time.h>
> -
> -#include <linux/bpf.h>
> -#include <bpf/bpf.h>
> -#include <bpf/libbpf.h>
> -
> -#include "cgroup_helpers.h"
> -#include "testing_helpers.h"
> -
> -#define DEV_CGROUP_PROG "./dev_cgroup.bpf.o"
> -
> -#define TEST_CGROUP "/test-bpf-based-device-cgroup/"
> -
> -int main(int argc, char **argv)
> -{
> - struct bpf_object *obj;
> - int error = EXIT_FAILURE;
> - int prog_fd, cgroup_fd;
> - __u32 prog_cnt;
> -
> - /* Use libbpf 1.0 API mode */
> - libbpf_set_strict_mode(LIBBPF_STRICT_ALL);
> -
> - if (bpf_prog_test_load(DEV_CGROUP_PROG, BPF_PROG_TYPE_CGROUP_DEVICE,
> - &obj, &prog_fd)) {
> - printf("Failed to load DEV_CGROUP program\n");
> - goto out;
> - }
> -
> - cgroup_fd = cgroup_setup_and_join(TEST_CGROUP);
> - if (cgroup_fd < 0) {
> - printf("Failed to create test cgroup\n");
> - goto out;
> - }
> -
> - /* Attach bpf program */
> - if (bpf_prog_attach(prog_fd, cgroup_fd, BPF_CGROUP_DEVICE, 0)) {
> - printf("Failed to attach DEV_CGROUP program");
> - goto err;
> - }
> -
> - if (bpf_prog_query(cgroup_fd, BPF_CGROUP_DEVICE, 0, NULL, NULL,
> - &prog_cnt)) {
> - printf("Failed to query attached programs");
> - goto err;
> - }
> -
> - /* All operations with /dev/zero and and /dev/urandom are allowed,
> - * everything else is forbidden.
> - */
> - assert(system("rm -f /tmp/test_dev_cgroup_null") == 0);
> - assert(system("mknod /tmp/test_dev_cgroup_null c 1 3"));
> - assert(system("rm -f /tmp/test_dev_cgroup_null") == 0);
> -
> - /* /dev/zero is whitelisted */
> - assert(system("rm -f /tmp/test_dev_cgroup_zero") == 0);
> - assert(system("mknod /tmp/test_dev_cgroup_zero c 1 5") == 0);
> - assert(system("rm -f /tmp/test_dev_cgroup_zero") == 0);
> -
> - assert(system("dd if=/dev/urandom of=/dev/zero count=64") == 0);
> -
> - /* src is allowed, target is forbidden */
> - assert(system("dd if=/dev/urandom of=/dev/full count=64"));
> -
> - /* src is forbidden, target is allowed */
> - assert(system("dd if=/dev/random of=/dev/zero count=64"));
> -
> - error = 0;
> - printf("test_dev_cgroup:PASS\n");
> -
> -err:
> - cleanup_cgroup_environment();
> -
> -out:
> - return error;
> -}
Yonghong Song,
Thank you so much for replying. I was missing how to run pipeline manually.
Thanks a ton.
On 4/1/24 11:53 PM, Yonghong Song wrote:
>
> On 4/1/24 5:34 AM, Muhammad Usama Anjum wrote:
>> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
>> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
>> dev_cgroup.skel.h and load program from it accourdingly.
>>
>> ./test_progs -t dev_cgroup
>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>> 64+0 records in
>> 64+0 records out
>> 32768 bytes (33 kB, 32 KiB) copied, 0.000856684 s, 38.2 MB/s
>> dd: failed to open '/dev/full': Operation not permitted
>> dd: failed to open '/dev/random': Operation not permitted
>> #72 test_dev_cgroup:OK
>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>> Signed-off-by: Muhammad Usama Anjum <[email protected]>
>> ---
>> Changes since v2:
>> - Replace test_dev_cgroup with serial_test_dev_cgroup as there is
>> probability that the test is racing against another cgroup test
>> - Minor changes to the commit message above
>>
>> I've tested the patch with vmtest.sh on bpf-next/for-next and linux
>> next. It is passing on both. Not sure why it was failed on BPFCI.
>> Test run with vmtest.h:
>> sudo LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh
>> ./test_progs -t dev_cgroup
>> ./test_progs -t dev_cgroup
>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>> 64+0 records in
>> 64+0 records out
>> 32768 bytes (33 kB, 32 KiB) copied, 0.000403432 s, 81.2 MB/s
>> dd: failed to open '/dev/full': Operation not permitted
>> dd: failed to open '/dev/random': Operation not permitted
>> #69 dev_cgroup:OK
>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>
> The CI failure:
>
>
> Error: #72 dev_cgroup
> serial_test_dev_cgroup:PASS:skel_open_and_load 0 nsec
> serial_test_dev_cgroup:PASS:cgroup_setup_and_join 0 nsec
> serial_test_dev_cgroup:PASS:bpf_attach 0 nsec
> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
> serial_test_dev_cgroup:PASS:rm 0 nsec
> serial_test_dev_cgroup:PASS:mknod 0 nsec
> serial_test_dev_cgroup:PASS:rm 0 nsec
> serial_test_dev_cgroup:PASS:rm 0 nsec
> serial_test_dev_cgroup:FAIL:mknod unexpected mknod: actual 256 != expected 0
> serial_test_dev_cgroup:PASS:rm 0 nsec
> serial_test_dev_cgroup:PASS:dd 0 nsec
> serial_test_dev_cgroup:PASS:dd 0 nsec
> serial_test_dev_cgroup:PASS:dd 0 nsec
>
> (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
>
> The error code 256 means mknod execution has some issues. Maybe you need to
> find specific errno to find out what is going on. I think you can do ci
> on-demanding test to debug.
errno is 2 --> No such file or directory
Locally I'm unable to reproduce it until I don't remove
rm -f /tmp/test_dev_cgroup_zero such that the /tmp/test_dev_cgroup_zero
node is present before test execution. The error code is 256 with errno 2.
I'm debugging by placing system("ls /tmp 1>&2"); to find out which files
are already present in /tmp. But ls's output doesn't appear on the CI logs.
>
> https://www.kernel.org/doc/Documentation/bpf/bpf_devel_QA.rst
>
--
BR,
Muhammad Usama Anjum
On 4/2/24 8:16 AM, Muhammad Usama Anjum wrote:
> Yonghong Song,
>
> Thank you so much for replying. I was missing how to run pipeline manually.
> Thanks a ton.
>
> On 4/1/24 11:53 PM, Yonghong Song wrote:
>> On 4/1/24 5:34 AM, Muhammad Usama Anjum wrote:
>>> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
>>> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
>>> dev_cgroup.skel.h and load program from it accourdingly.
>>>
>>> ./test_progs -t dev_cgroup
>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>> 64+0 records in
>>> 64+0 records out
>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000856684 s, 38.2 MB/s
>>> dd: failed to open '/dev/full': Operation not permitted
>>> dd: failed to open '/dev/random': Operation not permitted
>>> #72 test_dev_cgroup:OK
>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>> Signed-off-by: Muhammad Usama Anjum <[email protected]>
>>> ---
>>> Changes since v2:
>>> - Replace test_dev_cgroup with serial_test_dev_cgroup as there is
>>> probability that the test is racing against another cgroup test
>>> - Minor changes to the commit message above
>>>
>>> I've tested the patch with vmtest.sh on bpf-next/for-next and linux
>>> next. It is passing on both. Not sure why it was failed on BPFCI.
>>> Test run with vmtest.h:
>>> sudo LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh
>>> ./test_progs -t dev_cgroup
>>> ./test_progs -t dev_cgroup
>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>> 64+0 records in
>>> 64+0 records out
>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000403432 s, 81.2 MB/s
>>> dd: failed to open '/dev/full': Operation not permitted
>>> dd: failed to open '/dev/random': Operation not permitted
>>> #69 dev_cgroup:OK
>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>> The CI failure:
>>
>>
>> Error: #72 dev_cgroup
>> serial_test_dev_cgroup:PASS:skel_open_and_load 0 nsec
>> serial_test_dev_cgroup:PASS:cgroup_setup_and_join 0 nsec
>> serial_test_dev_cgroup:PASS:bpf_attach 0 nsec
>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>> serial_test_dev_cgroup:PASS:rm 0 nsec
>> serial_test_dev_cgroup:PASS:mknod 0 nsec
>> serial_test_dev_cgroup:PASS:rm 0 nsec
>> serial_test_dev_cgroup:PASS:rm 0 nsec
>> serial_test_dev_cgroup:FAIL:mknod unexpected mknod: actual 256 != expected 0
>> serial_test_dev_cgroup:PASS:rm 0 nsec
>> serial_test_dev_cgroup:PASS:dd 0 nsec
>> serial_test_dev_cgroup:PASS:dd 0 nsec
>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>
>> (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
>>
>> The error code 256 means mknod execution has some issues. Maybe you need to
>> find specific errno to find out what is going on. I think you can do ci
>> on-demanding test to debug.
> errno is 2 --> No such file or directory
>
> Locally I'm unable to reproduce it until I don't remove
> rm -f /tmp/test_dev_cgroup_zero such that the /tmp/test_dev_cgroup_zero
> node is present before test execution. The error code is 256 with errno 2.
> I'm debugging by placing system("ls /tmp 1>&2"); to find out which files
> are already present in /tmp. But ls's output doesn't appear on the CI logs.
errno 2 means ENOENT.
From mknod man page (https://linux.die.net/man/2/mknod), it means
A directory component in/pathname/ does not exist or is a dangling symbolic link.
It means /tmp does not exist or a dangling symbolic link.
It is indeed very strange. To make the test robust, maybe creating a temp
directory with mkdtemp and use it as the path? The temp directory
creation should be done before bpf prog attach.
>
>> https://www.kernel.org/doc/Documentation/bpf/bpf_devel_QA.rst
>>
On 4/3/24 7:36 AM, Yonghong Song wrote:
>
> On 4/2/24 8:16 AM, Muhammad Usama Anjum wrote:
>> Yonghong Song,
>>
>> Thank you so much for replying. I was missing how to run pipeline manually.
>> Thanks a ton.
>>
>> On 4/1/24 11:53 PM, Yonghong Song wrote:
>>> On 4/1/24 5:34 AM, Muhammad Usama Anjum wrote:
>>>> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
>>>> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
>>>> dev_cgroup.skel.h and load program from it accourdingly.
>>>>
>>>> ./test_progs -t dev_cgroup
>>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>>> 64+0 records in
>>>> 64+0 records out
>>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000856684 s, 38.2 MB/s
>>>> dd: failed to open '/dev/full': Operation not permitted
>>>> dd: failed to open '/dev/random': Operation not permitted
>>>> #72 test_dev_cgroup:OK
>>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>>> Signed-off-by: Muhammad Usama Anjum <[email protected]>
>>>> ---
>>>> Changes since v2:
>>>> - Replace test_dev_cgroup with serial_test_dev_cgroup as there is
>>>> probability that the test is racing against another cgroup test
>>>> - Minor changes to the commit message above
>>>>
>>>> I've tested the patch with vmtest.sh on bpf-next/for-next and linux
>>>> next. It is passing on both. Not sure why it was failed on BPFCI.
>>>> Test run with vmtest.h:
>>>> sudo LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh
>>>> ./test_progs -t dev_cgroup
>>>> ./test_progs -t dev_cgroup
>>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>>> 64+0 records in
>>>> 64+0 records out
>>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000403432 s, 81.2 MB/s
>>>> dd: failed to open '/dev/full': Operation not permitted
>>>> dd: failed to open '/dev/random': Operation not permitted
>>>> #69 dev_cgroup:OK
>>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>> The CI failure:
>>>
>>>
>>> Error: #72 dev_cgroup
>>> serial_test_dev_cgroup:PASS:skel_open_and_load 0 nsec
>>> serial_test_dev_cgroup:PASS:cgroup_setup_and_join 0 nsec
>>> serial_test_dev_cgroup:PASS:bpf_attach 0 nsec
>>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>> serial_test_dev_cgroup:PASS:mknod 0 nsec
>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>> serial_test_dev_cgroup:FAIL:mknod unexpected mknod: actual 256 !=
>>> expected 0
>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>>
>>> (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
>>>
>>> The error code 256 means mknod execution has some issues. Maybe you need to
>>> find specific errno to find out what is going on. I think you can do ci
>>> on-demanding test to debug.
>> errno is 2 --> No such file or directory
>>
>> Locally I'm unable to reproduce it until I don't remove
>> rm -f /tmp/test_dev_cgroup_zero such that the /tmp/test_dev_cgroup_zero
>> node is present before test execution. The error code is 256 with errno 2.
>> I'm debugging by placing system("ls /tmp 1>&2"); to find out which files
>> are already present in /tmp. But ls's output doesn't appear on the CI logs.
>
> errno 2 means ENOENT.
> From mknod man page (https://linux.die.net/man/2/mknod), it means
> A directory component in/pathname/ does not exist or is a dangling
> symbolic link.
>
> It means /tmp does not exist or a dangling symbolic link.
> It is indeed very strange. To make the test robust, maybe creating a temp
> directory with mkdtemp and use it as the path? The temp directory
> creation should be done before bpf prog attach.
I've tried following but still no luck:
* /tmp is already present. Then I thought maybe the desired file is already
present. I've verified that there isn't file of same name is present inside
/tmp.
* I thought maybe mknod isn't present in the system. But mknod --help succeeds.
* I switched from /tmp to current directory to create the mknod. But the
result is same error.
* I've tried to use the same kernel config as the BPF CI is using. I'm not
able to reproduce it.
Not sure which edge case or what's going on. The problem is appearing
because of some limitation in the rootfs.
--
BR,
Muhammad Usama Anjum
On 4/3/24 5:03 AM, Muhammad Usama Anjum wrote:
> On 4/3/24 7:36 AM, Yonghong Song wrote:
>> On 4/2/24 8:16 AM, Muhammad Usama Anjum wrote:
>>> Yonghong Song,
>>>
>>> Thank you so much for replying. I was missing how to run pipeline manually.
>>> Thanks a ton.
>>>
>>> On 4/1/24 11:53 PM, Yonghong Song wrote:
>>>> On 4/1/24 5:34 AM, Muhammad Usama Anjum wrote:
>>>>> Move test_dev_cgroup.c to prog_tests/dev_cgroup.c to be able to run it
>>>>> with test_progs. Replace dev_cgroup.bpf.o with skel header file,
>>>>> dev_cgroup.skel.h and load program from it accourdingly.
>>>>>
>>>>> ./test_progs -t dev_cgroup
>>>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>>>> 64+0 records in
>>>>> 64+0 records out
>>>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000856684 s, 38.2 MB/s
>>>>> dd: failed to open '/dev/full': Operation not permitted
>>>>> dd: failed to open '/dev/random': Operation not permitted
>>>>> #72 test_dev_cgroup:OK
>>>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>>>> Signed-off-by: Muhammad Usama Anjum <[email protected]>
>>>>> ---
>>>>> Changes since v2:
>>>>> - Replace test_dev_cgroup with serial_test_dev_cgroup as there is
>>>>> probability that the test is racing against another cgroup test
>>>>> - Minor changes to the commit message above
>>>>>
>>>>> I've tested the patch with vmtest.sh on bpf-next/for-next and linux
>>>>> next. It is passing on both. Not sure why it was failed on BPFCI.
>>>>> Test run with vmtest.h:
>>>>> sudo LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh
>>>>> ./test_progs -t dev_cgroup
>>>>> ./test_progs -t dev_cgroup
>>>>> mknod: /tmp/test_dev_cgroup_null: Operation not permitted
>>>>> 64+0 records in
>>>>> 64+0 records out
>>>>> 32768 bytes (33 kB, 32 KiB) copied, 0.000403432 s, 81.2 MB/s
>>>>> dd: failed to open '/dev/full': Operation not permitted
>>>>> dd: failed to open '/dev/random': Operation not permitted
>>>>> #69 dev_cgroup:OK
>>>>> Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>>>> The CI failure:
>>>>
>>>>
>>>> Error: #72 dev_cgroup
>>>> serial_test_dev_cgroup:PASS:skel_open_and_load 0 nsec
>>>> serial_test_dev_cgroup:PASS:cgroup_setup_and_join 0 nsec
>>>> serial_test_dev_cgroup:PASS:bpf_attach 0 nsec
>>>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>>>> serial_test_dev_cgroup:PASS:bpf_query 0 nsec
>>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>>> serial_test_dev_cgroup:PASS:mknod 0 nsec
>>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>>> serial_test_dev_cgroup:FAIL:mknod unexpected mknod: actual 256 !=
>>>> expected 0
>>>> serial_test_dev_cgroup:PASS:rm 0 nsec
>>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>>> serial_test_dev_cgroup:PASS:dd 0 nsec
>>>>
>>>> (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
>>>>
>>>> The error code 256 means mknod execution has some issues. Maybe you need to
>>>> find specific errno to find out what is going on. I think you can do ci
>>>> on-demanding test to debug.
>>> errno is 2 --> No such file or directory
>>>
>>> Locally I'm unable to reproduce it until I don't remove
>>> rm -f /tmp/test_dev_cgroup_zero such that the /tmp/test_dev_cgroup_zero
>>> node is present before test execution. The error code is 256 with errno 2.
>>> I'm debugging by placing system("ls /tmp 1>&2"); to find out which files
>>> are already present in /tmp. But ls's output doesn't appear on the CI logs.
>> errno 2 means ENOENT.
>> From mknod man page (https://linux.die.net/man/2/mknod), it means
>> A directory component in/pathname/ does not exist or is a dangling
>> symbolic link.
>>
>> It means /tmp does not exist or a dangling symbolic link.
>> It is indeed very strange. To make the test robust, maybe creating a temp
>> directory with mkdtemp and use it as the path? The temp directory
>> creation should be done before bpf prog attach.
> I've tried following but still no luck:
> * /tmp is already present. Then I thought maybe the desired file is already
> present. I've verified that there isn't file of same name is present inside
> /tmp.
> * I thought maybe mknod isn't present in the system. But mknod --help succeeds.
> * I switched from /tmp to current directory to create the mknod. But the
> result is same error.
> * I've tried to use the same kernel config as the BPF CI is using. I'm not
> able to reproduce it.
>
> Not sure which edge case or what's going on. The problem is appearing
> because of some limitation in the rootfs.
Maybe you could collect /tmp mount options to see whether anything is
suspicious? In my vm, I have
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=3501540k,nr_inodes=1048576)
and the test works fine.