Re: [PATCH bpf-next v3 07/10] selftests/bpf: Add basic tests for resizable hash map

bot+bpf-ci
2026-04-24T20:32:46Z

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

> diff --git a/tools/testing/selftests/bpf/prog_tests/rhash.c b/tools/testing/selftests/bpf/prog_tests/rhash.c
> new file mode 100644
> index 000000000000..0f6eec4fe1fe
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/rhash.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2026 Meta Platforms, Inc. and affiliates. */
> +#include <test_progs.h>
> +#include <string.h>
> +#include <stdio.h>
> +#include "rhash.skel.h"
> +#include <linux/bpf.h>
> +#include <linux/perf_event.h>
> +#include <sys/syscall.h>
> +
> +static void rhash_run(const char *prog_name)
> +{
> + struct rhash *skel;
> + struct bpf_program *prog;
> + LIBBPF_OPTS(bpf_test_run_opts, opts);
> + int err;
> +
> + skel = rhash__open();
> + if (!ASSERT_OK_PTR(skel, "rhash__open"))
> + return;
> +
> + prog = bpf_object__find_program_by_name(skel->obj, prog_name);
> + if (!ASSERT_OK_PTR(prog, "bpf_object__find_program_by_name"))
> + goto cleanup;
> + bpf_program__set_autoload(prog, true);
> +
> + err = rhash__load(skel);
> + if (!ASSERT_OK(err, "skel_load"))
> + goto cleanup;
> +
> + err = bpf_prog_test_run_opts(bpf_program__fd(prog), &opts);
> + if (!ASSERT_OK(err, "prog run"))
> + goto cleanup;
> +
> + if (!ASSERT_OK(skel->bss->err, "bss->err"))
> + goto cleanup;

sashiko-bot@kernel.org raised a concern about the test framework potentially
missing BPF program failures. Can the test pass incorrectly if a BPF program
returns non-zero while skel->bss->err is zero?

Looking at test_rhash_update_delete() in progs/rhash.c:

err = bpf_map_delete_elem(&rhmap, &key);
if (err)
return 3;

e = bpf_map_lookup_elem(&rhmap, &key);
if (e)
return 4;

err = 0;
return 0;

If the final lookup finds an element when it shouldn't (e is not NULL), the
BPF program exits early with return 4. However, the global err variable was
just set to 0 by the successful bpf_map_delete_elem() call.

Since rhash_run() only checks ASSERT_OK(skel->bss->err) and doesn't check
opts.retval from bpf_prog_test_run_opts(), won't this allow the test to pass
when it should fail?

This issue appears in other subtests as well, where early return values like
1, 2, 3, 4, and 5 can be returned while err remains 0.

Reference: https://lore.kernel.org/bpf/20260424200255.D5C89C19425@smtp.kernel.org/

> +
> +cleanup:
> + rhash__destroy(skel);
> +}

[ ... ]

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24909591959