bpf: Introduce global percpu data

[kernel-patches-daemon-bpf]

Pull request for series with
subject: bpf: Introduce global percpu data
version: 5
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932

[kernel-patches-daemon-bpf]

Upstream branch: 50dff00
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-review-bot]

commit af562e49f6bb5fc55f01e80ac7a89327ad0f3bb3
Author: Leon Hwang <leon.hwang@linux.dev>

bpftool: Generate skeleton for global percpu data

This patch teaches bpftool to emit skeleton code for global percpu
variables, adding a nested per-object percpu structure and handling the
new .percpu data section in the generated open/load/destroy paths.

> 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

In-Reply-To-Subject: bpftool: Generate skeleton for global percpu data
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27147120330

[kernel-patches-daemon-bpf]

Forwarding comment 4650565744 via email
In-Reply-To: 20260608145113.65857-6-leon.hwang@linux.dev
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260608145113.65857-6-leon.hwang@linux.dev/

[kernel-patches-review-bot]

commit 5b7279c1a85c0a8f7dd35d670cf03f0a0256b5ad
Author: Leon Hwang <leon.hwang@linux.dev>

bpf: Introduce global percpu data

This patch adds global percpu data support, letting BPF programs define
percpu variables via SEC(".percpu") backed by a single-entry
BPF_MAP_TYPE_PERCPU_ARRAY.  It wires up map_direct_value_addr/meta for
percpu arrays and patches ld_imm64 of a percpu map value into a percpu
address mov at JIT fixup time.

Links:
[1] https://github.com/anakryiko/retsnoop
[2] https://github.com/bpfsnoop/bpfsnoop

> diff --git a/kernel/bpf/const_fold.c b/kernel/bpf/const_fold.c
> index b2a19acadb91..5787246bef30 100644
> --- a/kernel/bpf/const_fold.c
> +++ b/kernel/bpf/const_fold.c
> @@ -182,7 +182,6 @@ static void const_reg_xfer(struct bpf_verifier_env *env, struct const_arg_info *
>  		u64 val = 0;
>
>  		if (!bpf_map_is_rdonly(map) || !map->ops->map_direct_value_addr ||
> -		    map->map_type == BPF_MAP_TYPE_INSN_ARRAY ||
>  		    off < 0 || off + size > map->value_size ||
>  		    bpf_map_direct_read(map, off, size, &val, is_ldsx)) {
>  			*dst = unknown;

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 2690d063a240..eecd9ab82e91 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5556,6 +5556,8 @@ int bpf_map_direct_read(struct bpf_map *map, int off, int size, u64 *val,
>  	u64 addr;
>  	int err;
>
> +	if (map->map_type == BPF_MAP_TYPE_INSN_ARRAY || map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY)
> +		return -EINVAL;
>  	err = map->ops->map_direct_value_addr(map, &addr, off);

Here bpf_map_direct_read() now refuses both insn arrays and percpu arrays,
which makes sense since a percpu value address cannot be constant-folded
at verification time.

The const_fold.c hunk above was adjusted to cope with this: it dropped its
own BPF_MAP_TYPE_INSN_ARRAY pre-check and instead lets a bpf_map_direct_read()
failure fall through to "*dst = unknown".

Is the equivalent read path in check_mem_access() missing the same treatment?

kernel/bpf/verifier.c:check_mem_access() {
    ...
    /*
     * If map is read-only, track its contents as scalars,
     * unless it is an insn array (see the special case below)
     */
    if (tnum_is_const(reg->var_off) &&
        bpf_map_is_rdonly(map) &&
        map->ops->map_direct_value_addr &&
        map->map_type != BPF_MAP_TYPE_INSN_ARRAY) {
        int map_off = off + reg->var_off.value;
        u64 val = 0;

        err = bpf_map_direct_read(map, map_off, size, &val, is_ldsx);
        if (err)
            return err;
    ...
}

Since percpu_array_map_ops now sets map_direct_value_addr, a frozen percpu
array created with BPF_F_RDONLY_PROG satisfies this condition (it is rdonly,
has map_direct_value_addr, and is not an insn array).  It enters the branch,
calls bpf_map_direct_read(), gets the new -EINVAL, and returns it.

Does that mean a plain LDX from such a read-only percpu value is now rejected
at load time with a bare -EINVAL and no verbose() message, rather than being
tracked as an unknown scalar the way the const_fold.c path handles it (and the
way insn arrays are explicitly handled in the else-if below)?

Should this branch also exclude BPF_MAP_TYPE_PERCPU_ARRAY, so the load falls
through to mark_reg_unknown() instead of failing?

---

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

In-Reply-To-Subject: bpf: Introduce global percpu data
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27147120330

[kernel-patches-daemon-bpf]

Forwarding comment 4650789834 via email
In-Reply-To: 20260608145113.65857-3-leon.hwang@linux.dev
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/20260608145113.65857-3-leon.hwang@linux.dev/

[kernel-patches-daemon-bpf]

Upstream branch: b9452b5
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: dd0f968
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: f1a660b
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: 68f4e48
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: c15261b
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: 140fa23
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: 2e8ad1f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5

[kernel-patches-daemon-bpf]

Upstream branch: 30dee2c
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1107932
version: 5