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

Alexei Starovoitov
2026-04-16T15:36:39Z

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() ?