Re: [PATCH RFC bpf-next 2/3] selftests/bpf: Test inline_bpf_get_current_task() for LoongArch

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The expected BPF JIT inline instruction for `bpf_get_current_task()` on LoongArch incorrectly expects a pointer to `struct thread_info` instead of `struct task_struct`.
- [Medium] Adding test expectations for an unmerged kernel feature will cause the test suite to fail on LoongArch, breaking CI.
--

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

selftests/bpf: Test inline_bpf_get_current_task() for LoongArch

This commit adds the expected JIT inline instruction for bpf_get_current_task()
on LoongArch to the verifier_jit_inline selftest. It defines the expected JIT
output ahead of the actual JIT implementation being merged.

> Note that this test will pass only after the JIT inline support for
> bpf_get_current_task is merged. While the JIT inlining is still in
> the pipeline, adding the changes now will not introduce any build
> regressions.

Will this cause the selftest suite to fail on LoongArch in the meantime?

Since the JIT implementation is not yet merged, the test framework will likely
fall back to emitting a standard helper call instead of the expected inline
instruction. Adding test expectations for unmerged features often results in
test suite regressions until the corresponding feature lands.

> diff --git a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> index 4ea254063646..913a1699e42b 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_jit_inline.c
> @@ -10,6 +10,8 @@ __arch_x86_64
>  __jited("	addq	%gs:{{.*}}, %rax")
>  __arch_arm64
>  __jited("	mrs	x7, SP_EL0")
> +__arch_loongarch
> +__jited("	move	$a5, $tp")

Does this instruction return a pointer to struct thread_info instead of
struct task_struct?

On LoongArch, it appears the kernel stack holds struct thread_info, and the
$tp register points directly to it rather than to struct task_struct. The task
pointer is the first member of struct thread_info at offset 0.

By using a move instruction, the BPF program would receive the thread_info
pointer. When the program later attempts to access fields like task->pid, it
will read out-of-bounds stack memory relative to the thread_info base.

Should this be a memory load like ld.d $a5, $tp, 0 to dereference the task
pointer instead?

>  int inline_bpf_get_current_task(void)
>  {
>  	bpf_get_current_task();

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