Re: [PATCH RFC bpf-next v2 00/18] bpf: Introduce resizable hash map

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

On 4/16/26 3:11 PM, Alexei Starovoitov wrote:
> On Wed Apr 15, 2026 at 10:18 PM PDT, Herbert Xu wrote:
>> On Tue, Apr 14, 2026 at 10:13:21PM -0700, Alexei Starovoitov wrote:
>>>
>>> No need for such guarantees. It's best-effort only.
>>> If the walk skips entries it's fine.
>>> As long as it terminates eventually it's good.
>>
>> There is no guarantee that this walk will terminate (unless you
>> finish it in one go).  In a pathological scenario, after each
>> walk attempt, the hash table could be rehashed such that the
>> entry that you're resuming from gets moved back to bucket 0.
>>
>> More practically, the walk is essentially useless if you encounter
>> a rehash/resize event before calling rhashtable_walk_enter_from,
>> because half of the hash table could be missed because the entry
>> got moved near the end.
>>
>> I think a better interface is to detect such a rehash/resize event
>> and then fail the rhashtable_walk_enter_from call.
> 
> that's certainly a cleaner interface. the user can retry
> if resize occurs.
> 
There is a problem though is the get_next_key interface:

int get_next_key(struct bpf_map *map, void *key, void *next_key)

we cant store any metadata (table address) to check if rehash took 
place. Am I missing any way out of it?