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

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

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.