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

Mykyta Yatsenko
2026-04-16T16:30:59Z

On 4/16/26 4:36 PM, Alexei Starovoitov wrote:
> On Thu, Apr 16, 2026 at 8:10 AM Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>>
>>
>>
>> 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?
>
> Why store anything?
> rhashtable_walk_start_check() already returns -EAGAIN if resize
> happened. Propagate it as error from get_next_key() ?

Do we care if a resize happened between two separate get_next_key()?

get_next_key(a) → b
← rehash happens here
get_next_key(b) → c

The second call has no way to know that a rehash occurred. Because each
call to get_next_key() initializes/destroys a new walker and only active
walker can detect rehash took place.