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

Question

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(). This is a conntrack-like map - an entry contains some information about connection, a struct bpf_timer and expire field when this entry should be deleted due to inactivity, based on information in a connection (thus *_LRU map types are not suitable for me). So it's possible for a race condition here:

1. Thread 1 receives packet, does bpf_map_lookup_elem() and begins processing, at end of which bpf_timer_start() will be called to reschedule removal into future.

2. At moment after lookup, timer callback fires and does bpf_map_delete_elem() while first thread is not yet finished.

So how do I prevent two problems in this scenario?

• loss of state - when timer deletes record which actually should be renewed

• possible crash, if Thread 1 continues access to free'd memory (dangling pointer)