Re: [PATCH bpf-next v5 5/9] bpftool: Generate skeleton for global percpu data

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index 6ae7262ebe0c..e0c5c643fe9e 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c

[ ... ]

> @@ -254,6 +254,11 @@ static const struct btf_type *find_type_for_map(struct btf *btf, const char *map
>  	return NULL;
>  }
>
> +static bool bpf_map_is_percpu_data(const struct bpf_map *map)
> +{
> +	return bpf_map__is_internal(map) && bpf_map__type(map) == BPF_MAP_TYPE_PERCPU_ARRAY;
> +}
> +

[ ... ]

> @@ -847,7 +851,7 @@ static int gen_trace(struct bpf_object *obj, const char *obj_name, const char *h
>  	bpf_object__for_each_map(map, obj) {
>  		const char *mmap_flags;
>
> -		if (!is_mmapable_map(map, ident, sizeof(ident)))
> +		if (!is_mmapable_map(map, ident, sizeof(ident)) || bpf_map_is_percpu_data(map))
>  			continue;

By skipping the .percpu map here during light skeleton generation in
gen_trace(), is the user-space buffer for .percpu left writable?

If a user modifies skel->percpu after the light skeleton is loaded, will
that silently succeed without actually updating the kernel per-cpu map?

The regular skeleton path appears protected, since libbpf mprotect()s the
percpu mmaped buffer read-only at load in bpf_object__populate_internal_map().
For the light skeleton, gen_trace() skips the .percpu map, so its initial
value buffer is never finalized with skel_finalize_map_data() and never
mprotect()'d to PROT_READ, leaving it writable.

Does the generated light skeleton need an explicit mprotect(..., PROT_READ)
on the .percpu initial value buffer to enforce the read-only constraint
described in the commit message?

This was raised on v4 (https://lore.kernel.org/bpf/20260414212650.4F89BC19425@smtp.kernel.org/)
where the response was that the mprotect(..., PROT_READ) added in patch #4
should be moved into this patch so it isn't missed. The v5 code here looks
unchanged from v4, and the mprotect does not appear to have been moved in.

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