Re: [PATCH net-next] wireguard: use rhashtables instead of hashtables

["Jason A. Donenfeld" <Jason@zx2c4.com>]

On Sun, Jan 05, 2025 at 12:00:17PM +0100, Dmitrii Ermakov wrote:
> @@ -74,7 +75,6 @@ struct noise_handshake {
>  	u8 remote_static[NOISE_PUBLIC_KEY_LEN];
>  	u8 remote_ephemeral[NOISE_PUBLIC_KEY_LEN];
>  	u8 precomputed_static_static[NOISE_PUBLIC_KEY_LEN];
> -
>  	u8 preshared_key[NOISE_SYMMETRIC_KEY_LEN];
>  
>  	u8 hash[NOISE_HASH_LEN];
> @@ -83,6 +83,8 @@ struct noise_handshake {
>  	u8 latest_timestamp[NOISE_TIMESTAMP_LEN];
>  	__le32 remote_index;
>  
> +	siphash_key_t hash_seed;

Why?

> +#include "linux/printk.h"
> +#include "linux/rcupdate.h"
> +#include "linux/rhashtable-types.h"
> +#include "linux/rhashtable.h"
> +#include "linux/siphash.h"

Seems wrong.

> +#include "messages.h"
>  #include "peer.h"
>  #include "noise.h"
> +#include "linux/memory.h"

Ditto.

>  
> -static struct hlist_head *pubkey_bucket(struct pubkey_hashtable *table,
> -					const u8 pubkey[NOISE_PUBLIC_KEY_LEN])
> +static inline u32 index_hashfn(const void *data, u32 len, u32 seed)
>  {
> -	/* siphash gives us a secure 64bit number based on a random key. Since
> -	 * the bits are uniformly distributed, we can then mask off to get the
> -	 * bits we need.
> -	 */
> -	const u64 hash = siphash(pubkey, NOISE_PUBLIC_KEY_LEN, &table->key);
> +	const u32 *index = data;
> +	return *index;
> +}

But shouldn't this actually use siphash? What's happening here?

> +struct peer_hash_pubkey {
> +	siphash_key_t key;
> +	u8 pubkey[NOISE_PUBLIC_KEY_LEN];
> +};
> +
> +static inline u32 wg_peer_obj_hashfn(const void *data, u32 len, u32 seed)
> +{
> +	const struct wg_peer *peer = data;
> +	struct peer_hash_pubkey key;
> +	u64 hash;
> +
> +	memcpy(&key.key, &peer->handshake.hash_seed, sizeof(key.key));
> +	memcpy(&key.pubkey, &peer->handshake.remote_static, NOISE_PUBLIC_KEY_LEN);
> +
> +	hash = siphash(&key.pubkey, NOISE_PUBLIC_KEY_LEN, &key.key);

Why this weird construction with this other struct?

I'll stop reading here. There's a lot of strangeness with this patch.
Maybe it's workable with enough care, but I think to review this into
shape, in its current state, would be about the same as just rewriting
it.