Re: [PATCH bpf-next v3 03/10] bpf: Implement get_next_key() resizable hashtab

Mykyta Yatsenko
2026-04-28T13:20:53Z

On 4/28/26 11:33 AM, Herbert Xu wrote:
> On Fri, Apr 24, 2026 at 12:50:45PM -0700, Mykyta Yatsenko wrote:
>>
>> static int rhtab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
>> {
>> - return -EOPNOTSUPP;
>> + struct bpf_rhtab *rhtab = container_of(map, struct bpf_rhtab, map);
>> + struct rhashtable_iter iter;
>> + struct rhtab_elem *elem;
>> + int ret = -ENOENT;
>> +
>> + /*
>> + * Hold RCU across enter_from + walk_start to prevent the
>> + * element cached by enter_from from being freed before
>> + * walk_start re-acquires RCU.
>> + */
>> + guard(rcu)();
>> + /* If key is not found, places iterator at the beginning */
>> + rhashtable_walk_enter_from(&rhtab->ht, &iter, key, rhtab->params);
>> + rhashtable_walk_start(&iter);
>> +
>> + elem = rhtab_iter_next(&iter);
>> + if (elem) {
>> + memcpy(next_key, elem->data, map->key_size);
>> + ret = 0;
>> + }
>> +
>> + rhashtable_walk_stop(&iter);
>> + rhashtable_walk_exit(&iter);
>> +
>> + return ret;
>> }
>
> The same issue from v2 still exists here. If a rehash occurs
> in between calls to rhtab_map_get_next_key you could be iterating
> over the table forever.
>
> Cheers,

Yes, I agree that it is possible. For this function kernel does not
iterate the entire hashtable, each get_next_key() call comes from
userspace via syscall, maybe the risk is acceptable in this situation?

Other functions, where kernel does iterate over the rhashtable, it fails
and returns -EBUSY on resize.