diff mbox series

[bpf] selftests/bpf: Add a copyright notice to lpm_trie_map_get_next_key

Message ID Zyb6cVpIqmMBld4U@ub22 (mailing list archive)
State Rejected
Delegated to: BPF
Headers show
Series [bpf] selftests/bpf: Add a copyright notice to lpm_trie_map_get_next_key | expand

Checks

Context Check Description
bpf/vmtest-bpf-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-26 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-36 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-15 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-28 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-VM_Test-16 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-10 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-VM_Test-17 success Logs for set-matrix
bpf/vmtest-bpf-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-VM_Test-20 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-25 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-41 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-VM_Test-19 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-VM_Test-35 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-VM_Test-27 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-34 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-33 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-18 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-VM_Test-29 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-PR fail PR summary
bpf/vmtest-bpf-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-VM_Test-14 fail Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-VM_Test-21 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-VM_Test-13 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-VM_Test-22 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for bpf, async
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present fail Series targets non-next tree, but doesn't contain any Fixes tags
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 3 this patch: 3
netdev/build_tools success Errors and warnings before: 2 (+0) this patch: 2 (+0)
netdev/cc_maintainers warning 13 maintainers not CCed: shuah@kernel.org sdf@fomichev.me kpsingh@kernel.org john.fastabend@gmail.com eddyz87@gmail.com martin.lau@linux.dev song@kernel.org haoluo@google.com andrii@kernel.org yonghong.song@linux.dev mykolal@fb.com linux-kselftest@vger.kernel.org jolsa@kernel.org
netdev/build_clang success Errors and warnings before: 3 this patch: 3
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 3 this patch: 3
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 6 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Byeonguk Jeong Nov. 3, 2024, 4:22 a.m. UTC 
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(-)

Comments

Byeonguk Jeong Nov. 3, 2024, 6:04 a.m. UTC | #1 
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

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.
Hou Tao Nov. 4, 2024, 1:34 a.m. UTC | #2 
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.
> .
Byeonguk Jeong Nov. 4, 2024, 2:02 a.m. UTC | #3 
Okay, then do I need to resend this patch or it would be accepted anyway?
Ilya Leoshkevich Nov. 4, 2024, 10:07 a.m. UTC | #4 
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
Hou Tao Nov. 5, 2024, 2:34 a.m. UTC | #5 
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
Hou Tao Nov. 5, 2024, 2:39 a.m. UTC | #6 
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.
Hou Tao Nov. 5, 2024, 6:21 a.m. UTC | #7 
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
>
> .
diff mbox series

Patch

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>