.../testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Add a copyright notice that was missed at the commit
d7f214aeacb9 ("selftests/bpf: Add test for trie_get_next_key()")
Signed-off-by: Byeonguk Jeong <jungbu2855@gmail.com>
---
.../testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c b/tools/testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c
index 0ba015686492..3821d229cad3 100644
--- a/tools/testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c
+++ b/tools/testing/selftests/bpf/map_tests/lpm_trie_map_get_next_key.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0
-
+/* Copyright (c) 2024 Ahnlab, Inc. */
#define _GNU_SOURCE
#include <linux/bpf.h>
#include <stdio.h>
--
2.43.0Hi, The selftest "verifier_bits_iter/bad words" has been failed with retval 115, while I did not touched anything but a comment. Do you have any idea why it failed? I am not sure whether it indicates any bugs in the kernel. Best, Byeonguk On Sun, Nov 03, 2024 at 04:41:26AM +0000, bot+bpf-ci@kernel.org wrote: > Dear patch submitter, > > CI has tested the following submission: > Status: FAILURE > Name: [bpf] selftests/bpf: Add a copyright notice to lpm_trie_map_get_next_key > Patchwork: https://patchwork.kernel.org/project/netdevbpf/list/?series=905730&state=* > Matrix: https://github.com/kernel-patches/bpf/actions/runs/11648453401 > > Failed jobs: > test_progs_no_alu32-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/11648453401/job/32434970670 > > First test_progs failure (test_progs_no_alu32-s390x-gcc): > #433 verifier_bits_iter > tester_init:PASS:tester_log_buf 0 nsec > process_subtest:PASS:obj_open_mem 0 nsec > process_subtest:PASS:specs_alloc 0 nsec > #433/13 verifier_bits_iter/bad words > run_subtest:PASS:obj_open_mem 0 nsec > run_subtest:PASS:unexpected_load_failure 0 nsec > do_prog_test_run:PASS:bpf_prog_test_run 0 nsec > run_subtest:FAIL:1035 Unexpected retval: 115 != 0 > > > Please note: this email is coming from an unmonitored mailbox. If you have > questions or feedback, please reach out to the Meta Kernel CI team at > kernel-ci@meta.com.
Hi, On 11/3/2024 2:04 PM, Byeonguk Jeong wrote: > Hi, > > The selftest "verifier_bits_iter/bad words" has been failed with > retval 115, while I did not touched anything but a comment. > > Do you have any idea why it failed? I am not sure whether it indicates > any bugs in the kernel. > > Best, > Byeonguk Sorry for the inconvenience. It seems the test case "verifier_bits_iter/bad words" is flaky. It may fail randomly, such as in [1]. I think calling bpf_probe_read_kernel_common() on 3GB addr under s390 host may succeed and the content of the memory address will decide whether the test case will succeed or not. Do not know the reason why reading 3GB address succeeds under s390. Hope to get some insight from Ilya. I think we could fix the failure first by using NULL as the address of bad words just like null_pointer test case does. Will merge the test in bad_words into the null_pointer case. [1]: https://github.com/kernel-patches/bpf/actions/runs/11625956355/job/32377297736 > > On Sun, Nov 03, 2024 at 04:41:26AM +0000, bot+bpf-ci@kernel.org wrote: >> Dear patch submitter, >> >> CI has tested the following submission: >> Status: FAILURE >> Name: [bpf] selftests/bpf: Add a copyright notice to lpm_trie_map_get_next_key >> Patchwork: https://patchwork.kernel.org/project/netdevbpf/list/?series=905730&state=* >> Matrix: https://github.com/kernel-patches/bpf/actions/runs/11648453401 >> >> Failed jobs: >> test_progs_no_alu32-s390x-gcc: https://github.com/kernel-patches/bpf/actions/runs/11648453401/job/32434970670 >> >> First test_progs failure (test_progs_no_alu32-s390x-gcc): >> #433 verifier_bits_iter >> tester_init:PASS:tester_log_buf 0 nsec >> process_subtest:PASS:obj_open_mem 0 nsec >> process_subtest:PASS:specs_alloc 0 nsec >> #433/13 verifier_bits_iter/bad words >> run_subtest:PASS:obj_open_mem 0 nsec >> run_subtest:PASS:unexpected_load_failure 0 nsec >> do_prog_test_run:PASS:bpf_prog_test_run 0 nsec >> run_subtest:FAIL:1035 Unexpected retval: 115 != 0 >> >> >> Please note: this email is coming from an unmonitored mailbox. If you have >> questions or feedback, please reach out to the Meta Kernel CI team at >> kernel-ci@meta.com. > .
On Mon, 2024-11-04 at 09:34 +0800, Hou Tao wrote: > Hi, > > On 11/3/2024 2:04 PM, Byeonguk Jeong wrote: > > Hi, > > > > The selftest "verifier_bits_iter/bad words" has been failed with > > retval 115, while I did not touched anything but a comment. > > > > Do you have any idea why it failed? I am not sure whether it > > indicates > > any bugs in the kernel. > > > > Best, > > Byeonguk > > Sorry for the inconvenience. It seems the test case > "verifier_bits_iter/bad words" is flaky. It may fail randomly, such > as > in [1]. I think calling bpf_probe_read_kernel_common() on 3GB addr > under > s390 host may succeed and the content of the memory address will > decide > whether the test case will succeed or not. Do not know the reason why > reading 3GB address succeeds under s390. Hope to get some insight > from > Ilya. I think we could fix the failure first by using NULL as the > address of bad words just like null_pointer test case does. Will > merge > the test in bad_words into the null_pointer case. Hi, s390 kernel runs in a completely separate address space, there is no user/kernel split at TASK_SIZE. The same address may be valid in both the kernel and the user address spaces, there is no way to tell by looking at it. The config option related to this property is ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. Also, unfortunately, 0 is a valid address in the s390 kernel address space. I wonder if we could use -4095 as an address that cannot be dereferenced on all platforms? Best regards, Ilya
Hi Ilya, On 11/4/2024 6:07 PM, Ilya Leoshkevich wrote: > On Mon, 2024-11-04 at 09:34 +0800, Hou Tao wrote: >> Hi, >> >> On 11/3/2024 2:04 PM, Byeonguk Jeong wrote: >>> Hi, >>> >>> The selftest "verifier_bits_iter/bad words" has been failed with >>> retval 115, while I did not touched anything but a comment. >>> >>> Do you have any idea why it failed? I am not sure whether it >>> indicates >>> any bugs in the kernel. >>> >>> Best, >>> Byeonguk >> Sorry for the inconvenience. It seems the test case >> "verifier_bits_iter/bad words" is flaky. It may fail randomly, such >> as >> in [1]. I think calling bpf_probe_read_kernel_common() on 3GB addr >> under >> s390 host may succeed and the content of the memory address will >> decide >> whether the test case will succeed or not. Do not know the reason why >> reading 3GB address succeeds under s390. Hope to get some insight >> from >> Ilya. I think we could fix the failure first by using NULL as the >> address of bad words just like null_pointer test case does. Will >> merge >> the test in bad_words into the null_pointer case. > Hi, > > s390 kernel runs in a completely separate address space, there is no > user/kernel split at TASK_SIZE. The same address may be valid in both > the kernel and the user address spaces, there is no way to tell by > looking at it. The config option related to this property is > ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. > > Also, unfortunately, 0 is a valid address in the s390 kernel address > space. Thanks for the detailed explanation. It seems both arm and x86 have select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. > > I wonder if we could use -4095 as an address that cannot be > dereferenced on all platforms? I have tested it in both arm64 and x86-64 that reading from -4095 by using copy_from_kernel_nofault() will return -EFAULT . For s390, I hope the bpf CI could help to test it. Will post a fix patch later. > > Best regards, > Ilya
Hi, On 11/5/2024 10:34 AM, Hou Tao wrote: > Hi Ilya, > > On 11/4/2024 6:07 PM, Ilya Leoshkevich wrote: >> On Mon, 2024-11-04 at 09:34 +0800, Hou Tao wrote: >>> Hi, >>> >>> On 11/3/2024 2:04 PM, Byeonguk Jeong wrote: >>>> Hi, >>>> >>>> The selftest "verifier_bits_iter/bad words" has been failed with >>>> retval 115, while I did not touched anything but a comment. >>>> >>>> Do you have any idea why it failed? I am not sure whether it >>>> indicates >>>> any bugs in the kernel. >>>> >>>> Best, >>>> Byeonguk >>> Sorry for the inconvenience. It seems the test case >>> "verifier_bits_iter/bad words" is flaky. It may fail randomly, such >>> as >>> in [1]. I think calling bpf_probe_read_kernel_common() on 3GB addr >>> under >>> s390 host may succeed and the content of the memory address will >>> decide >>> whether the test case will succeed or not. Do not know the reason why >>> reading 3GB address succeeds under s390. Hope to get some insight >>> from >>> Ilya. I think we could fix the failure first by using NULL as the >>> address of bad words just like null_pointer test case does. Will >>> merge >>> the test in bad_words into the null_pointer case. >> Hi, >> >> s390 kernel runs in a completely separate address space, there is no >> user/kernel split at TASK_SIZE. The same address may be valid in both >> the kernel and the user address spaces, there is no way to tell by >> looking at it. The config option related to this property is >> ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. >> >> Also, unfortunately, 0 is a valid address in the s390 kernel address >> space. > Thanks for the detailed explanation. It seems both arm and x86 have > select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. >> I wonder if we could use -4095 as an address that cannot be >> dereferenced on all platforms? > I have tested it in both arm64 and x86-64 that reading from -4095 by > using copy_from_kernel_nofault() will return -EFAULT . For s390, I hope > the bpf CI could help to test it. Will post a fix patch later. On s390 host, it seems that using copy_from_kernel_nofault() to read from -4095 returns -EFAULT as well [1], so the suggestion works. Thanks again for the suggestion. [1] https://github.com/kernel-patches/bpf/actions/runs/11677589805/job/32515868794 >> Best regards, >> Ilya > > .
Okay, then do I need to resend this patch or it would be accepted anyway?
Hi, On 11/4/2024 10:02 AM, Byeonguk Jeong wrote: > Okay, then do I need to resend this patch or it would be accepted anyway? > > . It is decided by the maintainer. In my opinion, the patch is not urgent, so I think you can repost the patch later after v6.12 is released and change the target tree as bpf-next instead of bpf.
© 2016 - 2024 Red Hat, Inc.