Re: [PATCH v2] bpf: Annotate bpf_obj_memcpy with data_race

Sent with Proton Mail secure email.

On Thursday, August 20th, 2026 at PM 7:26, [email protected] <[email protected]> wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] bpf_obj_memcpy() ignores the long_memcpy parameter when a map value contains special BTF fields (rec != NULL), leading to data tearing and uninitialized memory leaks.
> --
> 
> --- Patch [1]: [PATCH v2] bpf: Annotate bpf_obj_memcpy with data_race ---
> commit 1f96f25bd23990e4a6c598225059cbcbac9898bf
> Author: quanyeyang <[email protected]>
> 
> bpf: Annotate bpf_obj_memcpy with data_race
> 
> This patch annotates the ordinary memcpy() sites in bpf_obj_memcpy() with
> data_race(), matching bpf_long_memcpy(). This documents the existing
> concurrency semantics and suppresses KCSAN reports for intentional races
> without changing behavior.

Thanks for the review.

The per-CPU padding issue is pre-existing and has already been fixed by
commit 7cf9cd98cf6f ("bpf: Copy per-CPU map value padding in
copy_map_value_long()"):

https://lore.kernel.org/bpf/[email protected]/

That commit makes copy_map_value_long() pass
round_up(map->value_size, 8) to bpf_obj_memcpy(), ensuring that the tail
padding is copied even when map->record is non-NULL.

My v2 was based on a Linus-tree commit that does not yet contain this
BPF-tree fix. The data_race() annotations neither introduce nor change
the padding behavior. I will make sure that the next revision is rebased
onto the current bpf tree.

As for tearing, bpf_long_memcpy() provides only a best-effort mitigation,
rather than a strict anti-tearing guarantee. The syzbot update paths
addressed by this patch use copy_map_value(), not copy_map_value_long().

quanyeyang