Map In-Place Atomic Increment while User-Space Access with syscall?

[thediveo]

After noticing the absence of a map type of BPF_MAP_TYPE_HISTOGRAM (we can dream, can't we?) I searched for existing open source that does histogram aggregation in kernel space using eBPF and so found runqlat.py here.

So I came across atomic_increment (e.g. here) that seems to get translated into an atomic increment operation.

Am I correct that this works on the map's bucket value in-place? If this is the case, how does this work under the RCU regime when the syscall for user space accessing a BPF_MAP_TYPE_HASH uses a byte copy operation that I assume boils down to something like a REP MOVS on the x86 architecture?

What are the underlying assumptions here that I'm missing so that the current code is RCU-safe?