Re: [PATCH v2] bpf: Fix percpu address space issues

[Eduard Zingerman <eddyz87@gmail.com>]

On Sun, 2024-08-11 at 18:13 +0200, Uros Bizjak wrote:
> In arraymap.c:
> 
> In bpf_array_map_seq_start() and bpf_array_map_seq_next()
> cast return values from the __percpu address space to
> the generic address space via uintptr_t [1].
> 
> Correct the declaration of pptr pointer in __bpf_array_map_seq_show()
> to void __percpu * and cast the value from the generic address
> space to the __percpu address space via uintptr_t [1].
> 
> In hashtab.c:
> 
> Assign the return value from bpf_mem_cache_alloc() to void pointer
> and cast the value to void __percpu ** (void pointer to percpu void
> pointer) before dereferencing.
> 
> In memalloc.c:
> 
> Explicitly declare __percpu variables.
> 
> Cast obj to void __percpu **.
> 
> In helpers.c:
> 
> Cast ptr in BPF_CALL_1 and BPF_CALL_2 from generic address space
> to __percpu address space via const uintptr_t [1].
> 
> Found by GCC's named address space checks.
> 
> There were no changes in the resulting object files.
> 
> [1] https://sparse.docs.kernel.org/en/latest/annotations.html#address-space-name
> 
> Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Andrii Nakryiko <andrii@kernel.org>
> Cc: Martin KaFai Lau <martin.lau@linux.dev>
> Cc: Eduard Zingerman <eddyz87@gmail.com>
> Cc: Song Liu <song@kernel.org>
> Cc: Yonghong Song <yonghong.song@linux.dev>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: KP Singh <kpsingh@kernel.org>
> Cc: Stanislav Fomichev <sdf@fomichev.me>
> Cc: Hao Luo <haoluo@google.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> ---
> v2: - cast return values from the __percpu address space to
>     the generic address space in bpf_array_map_seq_{start,next}().
>     - correct the declaration of pptr pointer in
>     __bpf_array_map_seq_show() to void __percpu *
> ---

Looks ok, thank you for applying suggested changes.
The only nit I have is that '(void *)(uintptr_t)p' (and it's inverse)
looks quite bulky, hiding it behind some macro might make some sense.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]