Re: [PATCH bpf-next v6 3/3] bpf: Cache build IDs in sleepable stackmap path

[bot+bpf-ci]

> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index 95336c0e8b56..0d641ac39227 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c

[ ... ]

> @@ -253,6 +261,17 @@ static void stack_map_get_build_id_offset_sleepable(struct bpf_stack_build_id *i
>  	for (u32 i = 0; i < trace_nr; i++) {
>  		ip = READ_ONCE(id_offs[i].ip);
>
> +		/*
> +		 * Range cache fast path: if ip falls within the previously
> +		 * resolved VMA range, reuse the cache build_id without
> +		 * re-acquiring the VMA lock.
> +		 */
> +		if (cache.build_id && ip >= cache.vm_start && ip < cache.vm_end) {
> +			offset = stack_map_build_id_offset(cache.vm_pgoff, cache.vm_start, ip);
> +			stack_map_build_id_set_valid(&id_offs[i], offset, cache.build_id);
> +			continue;
> +		}
> +
>  		vma = stack_map_lock_vma(&lock, ip);
>  		if (!vma || !vma->vm_file) {
>  			stack_map_build_id_set_ip(&id_offs[i]);

sashiko-bot@xxxxxxxxxx raised a concern in v3 (repeated in v4 and v5 by
bpf-ci) about the VMA classification here using !vma->vm_file. While
this check predates your patch series, it's worth addressing for the
context this code now operates in.

Can private mappings of /dev/zero or driver memory cause issues? These
mappings can have a non-NULL vma->vm_file but are still considered
anonymous. If the stackmap path proceeds to parse the ELF build ID from
these files, could it trigger unintended side effects?

For example, reading from a character device might alter hardware state,
or reading from a FIFO could consume data.

Would checking vma_is_anonymous(vma) here be safer to properly classify
the VMA?

Reference: https://lore.kernel.org/bpf/20260513043154.24483C2BCB7@xxxxxxxxxxxxxxx/

[ ... ]


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