Messages in this thread | | | Date | Sun, 24 Mar 2019 20:02:54 -0400 (EDT) | Subject | Re: [PATCH net-next v9 19/19] net: WireGuard secure network tunnel | From | David Miller <> |
| |
From: "Jason A. Donenfeld" <Jason@zx2c4.com> Date: Fri, 22 Mar 2019 01:11:22 -0600
> +static __always_inline void swap_endian(u8 *dst, const u8 *src, u8 bits) > +{
Unless you have an absolutely requirement on inlining (if uninlined, the compilation would break), you must not use the __always_inline keyword and you must let the compiler decide what to do.
Said another way: "The code isn't optimal with my compiler on my computer unless I force inline this" is not a valid reason to use __always_inline
And for this reason we never use __inline in foo.c files, always let the compiler decide.
This applies to your entire submission.
> + ((u64 *)dst)[0] = be64_to_cpu(((const __be64 *)src)[0]); > + ((u64 *)dst)[1] = be64_to_cpu(((const __be64 *)src)[1]);
Are 'dst' and 'src' both 64-bit aligned? If not you'll get traps on some cpus.
> + __skb_queue_head_init(&packets); > + if (!skb_is_gso(skb)) { > + skb->next = NULL;
Why? Direct ->next and ->prev pointer accesses should never be used, along with anything that assumes what the implentation of skb lists looks like.
Always use the helpers instead.
> diff --git a/drivers/net/wireguard/hashtables.c b/drivers/net/wireguard/hashtables.c > new file mode 100644 > index 000000000000..8aedc17b85f9 > --- /dev/null > +++ b/drivers/net/wireguard/hashtables.c
No way.
Do not invent your own hashtables, we have several generic versions in tree and in particular rhashtable.
If the generic kernel facilities have a weakness, fix that instead of rolling an entire new hashtable implementation.
| |