bpf: fix comment for helper bpf_current_task_under_cgroup() #44
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Master branch: 2f7de98 patch https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/ applied successfully |
|
Master branch: e3b9626 patch https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/ applied successfully |
kernel-patches-bot
force-pushed
the
series/200975
branch
from
d41acb5 to
0435ea6
Compare
|
Master branch: d66423f patch https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/ applied successfully |
kernel-patches-bot
force-pushed
the
series/200975
branch
from
0435ea6 to
26d82cb
Compare
Fixes: c6b5fb8 ("bpf: add documentation for eBPF helpers (42-50)") Cc: <[email protected]> Signed-off-by: Song Liu <[email protected]> --- include/uapi/linux/bpf.h | 4 ++-- tools/include/uapi/linux/bpf.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
|
Master branch: 90a1ded patch https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/ applied successfully |
kernel-patches-bot
force-pushed
the
series/200975
branch
from
26d82cb to
00bd3a5
Compare
|
At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=200975 irrelevant now. Closing PR. |
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 5, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 17, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 17, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 17, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 17, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 22, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 22, 2021
A test is added for arraymap and percpu arraymap. The test also
exercises the early return for the helper which does not
traverse all elements.
$ ./test_progs -n 44
#44/1 hash_map:OK
#44/2 array_map:OK
#44 for_each:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 23, 2021
A test case is added for hashmap and percpu hashmap. The test
also exercises nested bpf_for_each_map_elem() calls like
bpf_prog:
bpf_for_each_map_elem(func1)
func1:
bpf_for_each_map_elem(func2)
func2:
$ ./test_progs -n 44
#44/1 hash_map:OK
#44 for_each:OK
Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Yonghong Song <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Oct 29, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Oct 31, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 2, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 2, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 2, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 2, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 2, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 3, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 6, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 6, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 7, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 8, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 9, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 9, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 9, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 9, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 11, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 11, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 13, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 14, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 14, 2023
If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Jul 5, 2024
If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called. However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following: BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [kernel-patches#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 kernel-patches#44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Do not access ata_port struct members unconditionally. Fixes: 633273a ("libata-pmp: hook PMP support and enable it") Cc: [email protected] Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Niklas Cassel <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Mar 9, 2025
ieee80211_register_hw() takes the wiphy lock, and then register_netdevice() calls netdev_lock(), since commit 5fda3f3 ("net: make netdev_lock() protect netdev->reg_state"). On the other hand, do_setlink() calls netdev_lock() and then ieee80211_change_mac() takes the wiphy lock, after commit df43d8b ("net: replace dev_addr_sem with netdev instance lock"). This causes the circular locking dependency. Like netdev_lock(), netdev_lock_ops() introduced in commit 97246d6 ("net: hold netdev instance lock during ndo_bpf") would also cause the same type of issue. Both netdev_lock() and netdev_lock_ops() are called before list_netdevice() in register_netdevice(). No other context can access the struct net_device, so we don't need these locks in this context. Remove them. WARNING: possible circular locking dependency detected 6.14.0-rc5-next-20250307 kernel-patches#44 Not tainted NetworkManager/8289 is trying to acquire lock: ffff88810fb30768 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_change_mac+0x110/0x1450 but task is already holding lock: ffff88810fb48d30 (&dev->lock){+.+.}-{4:4}, at: do_setlink.isra.0+0x326c/0x3f40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> kernel-patches#1 (&dev->lock){+.+.}-{4:4}: lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 register_netdevice+0x12dc/0x2000 cfg80211_register_netdevice+0x149/0x330 ieee80211_if_add+0xcfe/0x1880 ieee80211_register_hw+0x3655/0x3f60 mac80211_hwsim_new_radio+0x2760/0x53a0 init_mac80211_hwsim+0x6c6/0x7d0 do_one_initcall+0x11a/0x6d0 kernel_init_freeable+0x6dd/0x770 kernel_init+0x1f/0x1e0 ret_from_fork+0x45/0x80 ret_from_fork_asm+0x1a/0x30 -> #0 (&rdev->wiphy.mtx){+.+.}-{4:4}: check_prev_add+0x1af/0x23e0 __lock_acquire+0x2d55/0x49a0 lock_acquire+0x1b2/0x550 __mutex_lock+0x1a2/0x14b0 ieee80211_change_mac+0x110/0x1450 netif_set_mac_address+0x30a/0x4a0 do_setlink.isra.0+0x77a/0x3f40 rtnl_newlink+0x11ef/0x2370 rtnetlink_rcv_msg+0x95b/0xe90 netlink_rcv_skb+0x16b/0x440 netlink_unicast+0x532/0x7f0 netlink_sendmsg+0x8ca/0xda0 ____sys_sendmsg+0x9cf/0xb60 ___sys_sendmsg+0x11a/0x1a0 __sys_sendmsg+0x136/0x1e0 do_syscall_64+0x74/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->lock); lock(&rdev->wiphy.mtx); lock(&dev->lock); lock(&rdev->wiphy.mtx); *** DEADLOCK *** Fixes: df43d8b ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Kohei Enju <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: bpf: fix comment for helper bpf_current_task_under_cgroup()
version: 1
url: https://patchwork.ozlabs.org/project/netdev/list/?series=200975