Re: XDP/eBPF map thread safety in kernel (e.g. lookup/delete)

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Vadim Goncharov <vadimnuclight@gmail.com> writes:

> Hello,
>
> Where to find exact documentation about what happens in kernel BPF
> helpers calls with respect to locking? For example, I have
> `bpf_map_lookup_elem()` in one thread, then work on pointer, and at this
> time, another thread does `bpf_map_delete_elem()` for exactly same key.
> What happens to memory the first thread still continue to work on? Is
> it now dangling pointer to nowhere?
>
> In my particular case it's a bpf_timer callback who does
> `bpf_map_delete_elem()`. I'd prefer for it to not delete entry if
> another thread did `lookup` and works already, is it possible to do so
> (in a performant way)?

Map elements are RCU protected, so you already get exactly the behaviour
you're after: if another thread deletes a map element that you already
looked up, the element is guaranteed to stick around in memory until the
BPF program exits.

It won't be valid anymore *after* that of course, so if you're doing
concurrent updates it's you own responsibility to sync appropriately.
But there is no risk of the pointer suddenly being invalid in the middle
of the program execution (so no crashes) :)

-Toke