Re: [PATCH bpf-next v6 06/12] libbpf: Add support for global percpu data

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing endianness conversion for `flags` in `bpf_gen__map_update_elem` breaks cross-compiled BPF skeleton loaders.
--

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

libbpf: Add support for global percpu data

This commit adds support for global percpu data in libbpf by introducing a
new ".percpu" section. It updates the gen_loader to populate the percpu_array
map using the BPF_F_ALL_CPUS flag.

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index d79695f01c87f..7ceb096f18ecb 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c

[ ... ]

> @@ -1198,6 +1198,7 @@ void bpf_gen__map_update_elem(struct bpf_gen *gen, int map_idx, void *pvalue,
>  	int zero = 0;
>  
>  	memset(&attr, 0, attr_size);
> +	attr.flags = flags;

[Severity: High]
Does this assignment need to use tgt_endian() to support cross-compilation?

When libbpf generates a skeleton loader for a target architecture with a
different endianness than the host, fields populated into the union bpf_attr
blob usually need to be converted to the target byte order.

For global percpu data maps, this flag will be BPF_F_ALL_CPUS (0x10). If a
little-endian host generates a skeleton for a big-endian target, a direct
assignment of the 64-bit value could result in it being interpreted as
0x1000000000000000 by the target kernel, which would cause the sys_bpf
call to fail with -EINVAL.

>  
>  	value = add_data(gen, pvalue, value_size);
>  	key = add_data(gen, &zero, sizeof(zero));

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615152646.27639-1-leon.hwang@linux.dev?part=6