Re: [PATCH RFC bpf-next 3/3] selftests/bpf: Test jited inline of bpf_get_smp_processor_id()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The expected JIT assembly uses an incorrect struct offset (8 instead of 24), which dictates a memory-corrupting JIT implementation.
- [Medium] Adding a known-failing test breaks BPF CI and git bisection.
--

commit c320ef8cc6d3d14ed32f2590ea486674717257d9
Author: Tiezhu Yang <yangtiezhu@loongson.cn>

selftests/bpf: Test jited inline of bpf_get_smp_processor_id()

Add the testcase for the jited inline of bpf_get_smp_processor_id(),
only for LoongArch currently.

>     Note that this test will pass only after the JIT inline support for
>     bpf_get_smp_processor_id is merged. While the JIT inlining is still
>     in the pipeline, adding the changes now will not introduce any build
>     regressions. It serves to define the expected JIT output for future
>     validation.

Is it expected that this breaks BPF CI and git bisection?

Introducing a test for a feature that is not yet implemented causes the
test_progs suite to fail on LoongArch, because the BPF test framework's
__jited tag will fail the test when it does not find the expected JIT
instructions.

Tests for new features are typically submitted and merged in the same patch
series as the feature itself to ensure the tree remains fully testable at
every commit.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> index 913a1699e42b..e4d683c8cb06 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> @@ -19,4 +19,15 @@ int inline_bpf_get_current_task(void)
>  	return 0;
>  }
>  
> +SEC("fentry/bpf_fentry_test2")
> +__success __retval(0)
> +__arch_loongarch
> +__jited("	ld.w	$a5, $tp, 8")

Does this expect an incorrect struct offset?

On LoongArch, $tp holds __current_thread_info (a pointer to struct
thread_info). In the kernel, struct thread_info places the cpu field at
offset 24. Reading from offset 8 will erroneously load the flags field
instead of the cpu ID.

If the BPF JIT implementation matches this test, returning flags instead of
the CPU ID could cause out-of-bounds memory accesses and kernel memory
corruption when bpf_get_smp_processor_id() is used to index per-CPU maps.

> +int inline_bpf_get_smp_processor_id(void)
> +{
> +	bpf_get_smp_processor_id();
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260428080051.20938-1-yangtiezhu@loongson.cn?part=3