Re: [PATCH v1 2/3] LoongArch: BPF: Inline bpf_get_current_task{_btf}() helpers

[bot+bpf-ci]

> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index 058ffbbaad85..7967de9395ec 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -1147,6 +1147,13 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, bool ext
>
>  	/* function call */
>  	case BPF_JMP | BPF_CALL:
> +		/* Implement helper call to bpf_get_current_task/_btf() inline */
> +		if (insn->src_reg == 0 && (insn->imm == BPF_FUNC_get_current_task ||
> +					   insn->imm == BPF_FUNC_get_current_task_btf)) {
> +			move_reg(ctx, regmap[BPF_REG_0], LOONGARCH_GPR_TP);
> +			break;
> +		}
> +

sashiko-bot raised a concern in v1 about the dependency on patch 1/3:
On 32-bit LoongArch builds, does __switch_to() add TASK_STRUCT_OFFSET
to the task pointer and store the biased pointer directly into $tp
without unbiasing it?

This patch directly reads $tp to get the task_struct pointer. If the
preceding patch (1/3) leaves a biased pointer in $tp on 32-bit builds,
wouldn't this inlined bpf_get_current_task() return an incorrect pointer
offset by TASK_STRUCT_OFFSET (2000 bytes)?

The concern originated from this review:
https://lore.kernel.org/all/20260608105329.610981F00893@xxxxxxxxxxxxxxx/

The original comment asked:

> Does this leave a biased task_struct pointer in the $tp register on
> 32-bit builds?
>
> Since the current macro is now directly mapped to $tp in
> arch/loongarch/include/asm/current.h:
>
> register struct task_struct *current_thread_pointer __asm__("$tp");
> #define current get_current()
>
> If a1 (next) has TASK_STRUCT_OFFSET added to it to bypass assembly
> immediate offset limitations on 32-bit builds, this move instruction
> places that biased pointer into $tp without unbiasing it before
> returning.
>
> When __switch_to() returns to C code, wouldn't evaluating the current
> macro dereference a pointer shifted by TASK_STRUCT_OFFSET (2000 bytes
> on 32-bit) and cause immediate memory corruption or kernel panics
> during context switch?

This comment does not appear to have been addressed.

[ ... ]


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