[PATCH bpf-next 0/4] selftests/bpf: Fix compilation with RELEASE=1

[PATCH bpf-next 0/4] selftests/bpf: Fix compilation with RELEASE=1

[Viktor Malik]

When compiling BPF selftests with RELEASE=1 (which most notably adds
-O2), GCC reports several warnings. These are by default treated as
errors and abort the compilation.

This series fixes all of the issues such that selftests can be compiled
with RELEASE=1.

Viktor Malik (4):
  selftests/bpf: Check malloc result with ASSERT_NEQ in test_loader
  selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256
  selftests/bpf: Silence array bounds warning in global_map_resize
  selftests/bpf: Silence maybe-uninitialized compiler warning in
    libarena

 .../selftests/bpf/libarena/include/libarena/userspace.h   | 2 +-
 .../testing/selftests/bpf/prog_tests/global_map_resize.c  | 8 ++++++--
 tools/testing/selftests/bpf/prog_tests/sha256.c           | 4 ++--
 tools/testing/selftests/bpf/test_loader.c                 | 2 +-
 4 files changed, 10 insertions(+), 6 deletions(-)

-- 
2.54.0

[PATCH bpf-next 1/4] selftests/bpf: Check malloc result with ASSERT_NEQ in test_loader

[Viktor Malik]

Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the
result of malloc. It is more accurate since malloc returns NULL, not an
error code, on failure and it also prevents the following false GCC
warning when compiling BPF selftests with -O2:

    In file included from test_loader.c:6:
    test_loader.c: In function ‘verify_stderr’:
    /bpf-next/tools/testing/selftests/bpf/test_progs.h:393:22: error: ‘buf’ may be used uninitialized [-Werror=maybe-uninitialized]
      393 |         int ___err = libbpf_get_error(___res);                          \
          |                      ^~~~~~~~~~~~~~~~~~~~~~~~
    test_loader.c:810:14: note: in expansion of macro ‘ASSERT_OK_PTR’
      810 |         if (!ASSERT_OK_PTR(buf, "malloc"))
          |              ^~~~~~~~~~~~~
    In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32,
                     from /bpf-next/tools/testing/selftests/bpf/test_progs.h:37:
    /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here
      113 | LIBBPF_API long libbpf_get_error(const void *ptr);
          |                 ^~~~~~~~~~~~~~~~

Signed-off-by: Viktor Malik <vmalik@redhat.com>
Fixes: 554e4eb9e4b7 ("selftests/bpf: Reuse stderr parsing for libarena ASAN tests")
---
 tools/testing/selftests/bpf/test_loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/test_loader.c b/tools/testing/selftests/bpf/test_loader.c
index 3ce32d134e2c..07807757b518 100644
--- a/tools/testing/selftests/bpf/test_loader.c
+++ b/tools/testing/selftests/bpf/test_loader.c
@@ -807,7 +807,7 @@ static void verify_stderr(int prog_fd, struct expected_msgs *msgs)
 		return;
 
 	buf = malloc(TEST_LOADER_LOG_BUF_SZ);
-	if (!ASSERT_OK_PTR(buf, "malloc"))
+	if (!ASSERT_NEQ(buf, NULL, "malloc"))
 		return;
 
 	ret = bpf_prog_stream_read(prog_fd, 2, buf, TEST_LOADER_LOG_BUF_SZ - 1,
-- 
2.54.0

[PATCH bpf-next 2/4] selftests/bpf: Check malloc result with ASSERT_NEQ in test_sha256

[Viktor Malik]

Replace ASSERT_OK_PTR by ASSERT_NEQ(res, NULL, ...) when checking the
result of malloc. It is more accurate since malloc returns NULL, not an
error code, on failure and it also prevents the following false GCC
warning when compiling BPF selftests with -O2:

    In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:4:
    /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c: In function ‘test_sha256’:
    ./test_progs.h:393:22: error: ‘data’ may be used uninitialized [-Werror=maybe-uninitialized]
      393 |         int ___err = libbpf_get_error(___res);                          \
          |                      ^~~~~~~~~~~~~~~~~~~~~~~~
    /bpf-next/tools/testing/selftests/bpf/prog_tests/sha256.c:28:14: note: in expansion of macro ‘ASSERT_OK_PTR’
       28 |         if (!ASSERT_OK_PTR(data, "malloc"))
          |              ^~~~~~~~~~~~~
    In file included from /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf.h:32,
                     from ./test_progs.h:37:
    /bpf-next/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here
      113 | LIBBPF_API long libbpf_get_error(const void *ptr);
          |                 ^~~~~~~~~~~~~~~~

Signed-off-by: Viktor Malik <vmalik@redhat.com>
Fixes: f09f57c74677 ("selftests/bpf: Add test for libbpf_sha256()")
---
 tools/testing/selftests/bpf/prog_tests/sha256.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/sha256.c b/tools/testing/selftests/bpf/prog_tests/sha256.c
index 604a0b1423d5..5edbc6194b07 100644
--- a/tools/testing/selftests/bpf/prog_tests/sha256.c
+++ b/tools/testing/selftests/bpf/prog_tests/sha256.c
@@ -25,10 +25,10 @@ void test_sha256(void)
 	size_t i;
 
 	data = malloc(MAX_LEN);
-	if (!ASSERT_OK_PTR(data, "malloc"))
+	if (!ASSERT_NEQ(data, NULL, "malloc"))
 		goto out;
 	digests = malloc((MAX_LEN + 1) * SHA256_DIGEST_LENGTH);
-	if (!ASSERT_OK_PTR(digests, "malloc"))
+	if (!ASSERT_NEQ(digests, NULL, "malloc"))
 		goto out;
 
 	/* Generate MAX_LEN bytes of "random" data deterministically. */
-- 
2.54.0

[PATCH bpf-next 3/4] selftests/bpf: Silence array bounds warning in global_map_resize

[Viktor Malik]

When compiling BPF selftests with -O2, GCC reports an array bounds
violation warning in global_map_resize test:

    In function ‘global_map_resize_bss_subtest’,
        inlined from ‘test_global_map_resize’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:228:3:
    /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:64:33: error: array subscript 1 is above array bounds of ‘int[1]’ [-Werror=array-bounds=]
       64 |                 skel->bss->array[i] = 1;
          |                 ~~~~~~~~~~~~~~~~^~~
    In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/global_map_resize.c:6:
    ./test_global_map_resize.skel.h: In function ‘test_global_map_resize’:
    ./test_global_map_resize.skel.h:44:21: note: while referencing ‘array’
       44 |                 int array[1];
          |                     ^~~~~

This is a false positive because `array` (a BPF map) has been resized
from within the BPF program. GCC doesn't know that so let us silence the
warning by accessing the array via a plain pointer.

Signed-off-by: Viktor Malik <vmalik@redhat.com>
Fixes: 08b089567573 ("libbpf: Selftests for resizing datasec maps")
---
 .../testing/selftests/bpf/prog_tests/global_map_resize.c  | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/global_map_resize.c b/tools/testing/selftests/bpf/prog_tests/global_map_resize.c
index 56b5baef35c8..602ce30f1720 100644
--- a/tools/testing/selftests/bpf/prog_tests/global_map_resize.c
+++ b/tools/testing/selftests/bpf/prog_tests/global_map_resize.c
@@ -23,6 +23,7 @@ static void global_map_resize_bss_subtest(void)
 	struct bpf_map *map;
 	const __u32 desired_sz = sizeof(skel->bss->sum) + sysconf(_SC_PAGE_SIZE) * 2;
 	size_t array_len, actual_sz, new_sz;
+	int *array;
 
 	skel = test_global_map_resize__open();
 	if (!ASSERT_OK_PTR(skel, "test_global_map_resize__open"))
@@ -58,10 +59,13 @@ static void global_map_resize_bss_subtest(void)
 		goto teardown;
 
 	/* fill the newly resized array with ones,
-	 * skipping the first element which was previously set
+	 * skipping the first element which was previously set;
+	 * access through a plain pointer to avoid -Warray-bounds
+	 * since the array was resized beyond its declared length.
 	 */
+	array = skel->bss->array;
 	for (int i = 1; i < array_len; i++)
-		skel->bss->array[i] = 1;
+		array[i] = 1;
 
 	/* set global const values before loading */
 	skel->rodata->pid = getpid();
-- 
2.54.0

[PATCH bpf-next 4/4] selftests/bpf: Silence maybe-uninitialized compiler warning in libarena

[Viktor Malik]

When compiling BPF selftests with -O2, GCC reports a maybe-uninitialized
warning in libarena code:

    In file included from /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:11:
    In function ‘libarena_asan_init’,
        inlined from ‘run_test’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:59:8,
        inlined from ‘test_libarena_asan’ at /bpf-next/tools/testing/selftests/bpf/prog_tests/libarena_asan.c:91:2:
    /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:126:14: error: ‘globals_pages’ may be used uninitialized [-Werror=maybe-uninitialized]
      126 |         args = (struct asan_init_args){
          |         ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
      127 |                 .arena_all_pages = arena_all_pages,
          |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      128 |                 .arena_globals_pages = globals_pages,
          |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      129 |         };
          |         ~
    /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h: In function ‘test_libarena_asan’:
    /bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h:118:13: note: ‘globals_pages’ was declared here
      118 |         u64 globals_pages;
          |             ^~~~~~~~~~~~~

Silence the warning by initializing globals_pages to 0.

Signed-off-by: Viktor Malik <vmalik@redhat.com>
Fixes: cfc00618b9df ("selftests/bpf: Add ASAN support for libarena selftests")
---
 .../testing/selftests/bpf/libarena/include/libarena/userspace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h b/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h
index fc27a4bcf5d7..b6676dd67bc0 100644
--- a/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h
+++ b/tools/testing/selftests/bpf/libarena/include/libarena/userspace.h
@@ -115,7 +115,7 @@ static inline int libarena_asan_init(int arena_asan_init_fd,
 {
 	LIBBPF_OPTS(bpf_test_run_opts, opts);
 	struct asan_init_args args;
-	u64 globals_pages;
+	u64 globals_pages = 0;
 	int ret;
 
 	ret = libarena_get_globals_pages(arena_asan_init_fd,
-- 
2.54.0

Re: [PATCH bpf-next 3/4] selftests/bpf: Silence array bounds warning in global_map_resize

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Multi-line comment opening '/*' is not on its own line.
--

--- Patch [3]: [PATCH bpf-next 3/4] selftests/bpf: Silence array bounds warning in global_map_resize ---
commit 477df4be9ab84dd41e948528c2cecec30f56ae6a
Author: Viktor Malik <vmalik@redhat.com>

selftests/bpf: Silence array bounds warning in global_map_resize

This commit silences a GCC false positive array bounds violation warning in
global_map_resize. It achieves this by accessing the BPF map array via a
plain pointer after it has been resized from within the BPF program.

> diff --git a/tools/testing/selftests/bpf/prog_tests/global_map_resize.c b/tools/testing/selftests/bpf/prog_tests/global_map_resize.c
> --- a/tools/testing/selftests/bpf/prog_tests/global_map_resize.c
> +++ b/tools/testing/selftests/bpf/prog_tests/global_map_resize.c

[ ... ]

> @@ -58,10 +59,13 @@ static void global_map_resize_bss_subtest(void)
>  		goto teardown;
>  
>  	/* fill the newly resized array with ones,
> -	 * skipping the first element which was previously set
> +	 * skipping the first element which was previously set;
> +	 * access through a plain pointer to avoid -Warray-bounds
> +	 * since the array was resized beyond its declared length.
>  	 */

[Severity: Low]
This isn't a bug, but does this multi-line comment follow the preferred BPF
coding style? 

The BPF subsystem guidelines require that multi-line comments have the
opening '/*' on its own line, even when modifying surrounding code that
uses the old style.

> +	array = skel->bss->array;
>  	for (int i = 1; i < array_len; i++)
> -		skel->bss->array[i] = 1;
> +		array[i] = 1;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784112948.git.vmalik@redhat.com?part=3

Re: [PATCH bpf-next 0/4] selftests/bpf: Fix compilation with RELEASE=1

[Kumar Kartikeya Dwivedi]

On Wed, 15 Jul 2026 at 13:22, Viktor Malik <vmalik@redhat.com> wrote:
>
> When compiling BPF selftests with RELEASE=1 (which most notably adds
> -O2), GCC reports several warnings. These are by default treated as
> errors and abort the compilation.
>
> This series fixes all of the issues such that selftests can be compiled
> with RELEASE=1.
>

Are these changes sufficient to fix all issues? I see more when I
compile with GCC 15 and RELEASE=1.
Also, is there no way to make ASSERT_OK_PTR work when we're testing
for non-NULL-ness? Having to change it to explicit != NULL is kinda
sad.

Re: [PATCH bpf-next 0/4] selftests/bpf: Fix compilation with RELEASE=1

[Viktor Malik]

On 7/15/26 14:10, Kumar Kartikeya Dwivedi wrote:
> On Wed, 15 Jul 2026 at 13:22, Viktor Malik <vmalik@redhat.com> wrote:
>>
>> When compiling BPF selftests with RELEASE=1 (which most notably adds
>> -O2), GCC reports several warnings. These are by default treated as
>> errors and abort the compilation.
>>
>> This series fixes all of the issues such that selftests can be compiled
>> with RELEASE=1.
>>
> 
> Are these changes sufficient to fix all issues? I see more when I
> compile with GCC 15 and RELEASE=1.

Strange, I tried compiling with both GCC 15 and 16 and these four
patches got rid of all the issues. Can you send the specific issues that
you see?

> Also, is there no way to make ASSERT_OK_PTR work when we're testing
> for non-NULL-ness? Having to change it to explicit != NULL is kinda
> sad.

ASSERT_OK_PTR uses libbpf_get_error(), which returns -errno when the
passed pointer is NULL. This is correct for checking pointers returned
from libbpf because libbpf always sets errno when it returns NULL as an
erroneous value of a pointer. However, that is not the case for other
library functions, such as malloc(), so calling libbpf_get_error() on
their result may actually return 0, if the function returned NULL and
never set errno. 

So, I'd say that in the current state, results of non-libbpf
ptr-returning functions should be checked with ASSERT_NEQ.
Alternatively, we can update ASSERT_OK_PTR to explicitly fail with a
default error code when NULL is passed, for example:

diff --git a/tools/testing/selftests/bpf/test_progs.h b/tools/testing/selftests/bpf/test_progs.h
index 2cf950afcd85..bf94b0947790 100644
--- a/tools/testing/selftests/bpf/test_progs.h
+++ b/tools/testing/selftests/bpf/test_progs.h
@@ -390,7 +390,7 @@ void hexdump(const char *prefix, const void *buf, size_t len);
 #define ASSERT_OK_PTR(ptr, name) ({                                    \
        static int duration = 0;                                        \
        const void *___res = (ptr);                                     \
-       int ___err = libbpf_get_error(___res);                          \
+       int ___err = ___res ? libbpf_get_error(___res) : -EINVAL;       \
        bool ___ok = ___err == 0;                                       \
        CHECK(!___ok, (name), "unexpected error: %d\n", ___err);        \
        ___ok;                                                          \

However, that would make us lose the error codes passed via errno from
libbpf.

Viktor