Re: [PATCHv3 bpf-next 02/12] bpf: Factor stackid_fastpath function from __bpf_get_stackid

--===============0379802954471312065==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

> bpf: Factor stackid_fastpath function from __bpf_get_stackid
>
> The new stackid_fastpath does the fast stack hash and trace check, that
> does not need new bucket allocation. It covers both just-ip and buildid
> code paths.
>
> Signed-off-by: Jiri Olsa <[email protected]>

This isn't a bug, but would it help to note in the changelog that -ENOENT
is the 'fall through to the slow path' return, and that hash_matches moves
into struct stackid so the slow path can still see it?

The caller depends on exactly that in:

> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> @@ -556,57 +575,45 @@ static long __bpf_get_stackid
>
> -	err = stackid_init(stackid, map, trace, flags);
> -	if (err)
> +	err = stackid_fastpath(stackid, map, trace, flags);
> +	if (err != -ENOENT)
>  		return err;

and the new bool hash_matches field exists so the predicate survives across
the function boundary. A 'no functional change intended' line would also
make the refactor easier to review.


---
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/30854471987
--===============0379802954471312065==--