Will update-or-insert-map result in breaking the guarantee for BPF_MAP_GET_NEXT_KEY to retrieve all the keys?

[nocomment500]

Hi all, I've encountered a wierd issue while transversing the bpf htab, while sometmes it seems the keys is missing during a full transversal, and I've found that there's a comment ahead of the MapIterator initialization which is taken by @lmb
"It's not possible to guarantee that all keys in a map will be returned if there are concurrent modifications to the map."
I feel confused somehow, does it mean that except for map deletion, map update(including insert) is also making BPF_MAP_GET_NEXT_KEY some chance to miss some key in the map under transversing?

I'm totally a novice to the kernel but I've got a slightly check on the code in my present used kernel code in version 4.9, the
htab_map_get_next_key will calculate the bucket every time, and since the htab_map_update_elem will always delete the original hash node and then hlist_add_head_rcu to add the new one, so will this node update cause the missing-some-keys problem when I've been transversing the whole map?

For a shorter version of the problem, for example, given there are entries 6, 2, 4, 5, 1 in the map, while the time I'm getting 2 from BPF_MAP_GET_NEXT_KEY, and simultaneously one other thread is executing insert for an entry like 3, will there be some possibilities that I will be missing the one of the 4, 5, 1 in the following invoke of BPF_MAP_GET_NEXT_KEY? (it's ok that 3 is not returned in this round of transversal)

[lmb]

I understand the kernel's behaviour like this:

• If you iterate while deletions are ongoing, you can hit the case that a key is deleted while trying to look it up. This causes a reset in the lookup.
• If you iterate while inserting or updating you may or may not see that inserted or updated key.

For a shorter version of the problem, for example, given there are entries 6, 2, 4, 5, 1 in the map, while the time I'm getting 2 from BPF_MAP_GET_NEXT_KEY, and simultaneously one other thread is executing insert for an entry like 3, will there be some possibilities that I will be missing the one of the 4, 5, 1 in the following invoke of BPF_MAP_GET_NEXT_KEY? (it's ok that 3 is not returned in this round of transversal)

Intuitively I think you should always see 4, 5, 1. I haven't checked though!