Re: [PATCH bpf-next 4/4] selftests/bpf: Add tests for pointer type merge at a shared load

> diff --git a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
> index b91271d4caa48..127b745bb0b7d 100644
> --- a/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c
> +++ b/tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c

[ ... ]

> +static __noinline u32 *get_mem_or_btf_id_addr(u32 *mem)
> +{
> +	struct task_struct *task;
> +
> +	/*
> +	 * Try to avoid compiler hoisting load to if branches by using
> +	 * __noinline func.
> +	 */
> +	if (zero)
> +		return mem;
> +
> +	task = bpf_get_current_task_btf();
> +	/*
> +	 * A plain BTF pointer walk yields a bare PTR_TO_BTF_ID, and
> +	 * task->nameidata is NULL unless the task currently is in the
> +	 * middle of a path lookup.
> +	 */
> +	return (u32 *)&task->nameidata->flags;
> +}

[ ... ]

> +static __noinline u32 *get_rdonly_mem_or_btf_id_addr(u32 *mem)
> +{
> +	struct task_struct *task;
> +
> +	/*
> +	 * Try to avoid compiler hoisting load to if branches by using
> +	 * __noinline func.
> +	 */
> +	if (zero)
> +		return mem;
> +
> +	task = bpf_get_current_task_btf();
> +	return (u32 *)&task->nameidata->flags;
> +}

This isn't a bug, but get_rdonly_mem_or_btf_id_addr() looks identical to
get_mem_or_btf_id_addr() above (same signature, same branch structure, same
BTF pointer walk). Since libbpf appends a referenced static subprog to every
main program that calls it anyway, could mixed_rdonly_mem_btf_id_type just
call the existing helper?


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