Re: [PATCH bpf-next v5 15/16] selftests/bpf: Add negative test for greater-than-8-byte kfunc stack argument

bot+bpf-ci
2026-04-18T00:52:31Z

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

> diff --git a/tools/testing/selftests/bpf/prog_tests/stack_arg_fail.c b/tools/testing/selftests/bpf/prog_tests/stack_arg_fail.c
> new file mode 100644
> index 000000000000..328a79edee45
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/stack_arg_fail.c
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2026 Meta Platforms, Inc. and affiliates. */
> +
> +#include <test_progs.h>
> +#include "stack_arg_fail.skel.h"
> +
> +void test_stack_arg_fail(void)
> +{
> + struct stack_arg_fail *skel;
> +
> + skel = stack_arg_fail__open();
> + if (!ASSERT_OK_PTR(skel, "open"))
> + return;
> +
> + if (!skel->rodata->has_stack_arg) {
> + test__skip();
> + goto out;
> + }
> +
> + ASSERT_ERR(stack_arg_fail__load(skel), "load_should_fail");

Could this generic error assertion mask the actual verifier rejection reason?

If the program fails to load due to an unrelated issue, such as a missing
BTF, a syntax error, or the architecture-dependent size mismatch described
below, the test will incorrectly report success because it only checks that
the load operation failed.

Would it be better to refactor this test to use the standard test_loader
infrastructure (via RUN_TESTS) with __failure and __msg annotations in the
BPF program? That would ensure the rejection is explicitly due to the
argument size limit.

> +
> +out:
> + stack_arg_fail__destroy(skel);
> +}

[ ... ]

> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h b/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> index 2c1cb118f886..2a40f80b074a 100644
> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> @@ -50,6 +50,11 @@ struct prog_test_pass2 {
> } x;
> };
>
> +struct prog_test_big_arg {
> + long a;
> + long b;
> +};

Does this structure achieve the intended >8 byte size on 32-bit architectures?

When the test kernel module is compiled on a 32-bit host, long is 32-bit,
making the struct exactly 8 bytes. Since the BPF target always treats long
as a 64-bit integer, this makes the struct 16 bytes in the BPF program.

This size discrepancy between the BPF program's BTF and the host kernel's
BTF might cause the verifier to reject the load for a BTF size mismatch
rather than the intended stack argument limit.

Could these fields use explicitly sized types like __u64 to ensure the
struct is consistently larger than 8 bytes across all architectures?

> +
> struct prog_test_fail1 {
> void *p;
> int x;

[ ... ]

---
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/24592562564