Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices

On 2/14/20 10:37 AM, Jason A. Donenfeld wrote:

On 2/14/20, Eric Dumazet [off-list ref] wrote:

quoted

On 2/14/20 10:15 AM, Jason A. Donenfeld wrote:

quoted

On Fri, Feb 14, 2020 at 6:56 PM Eric Dumazet [off-list ref]
wrote:

quoted

Oh dear, can you describe what do you expect of a wireguard device with
mtu == 0 or mtu == 1

Why simply not allowing silly configurations, instead of convoluted tests
in fast path ?

We are speaking of tunnels adding quite a lot of headers, so we better
not try to make them
work on networks with tiny mtu. Just say no to syzbot.

The idea was that wireguard might still be useful for the persistent
keepalive stuff. This branch becomes very cold very fast, so I don't
think it makes a difference performance wise, but if you feel strongly
about it, I can get rid of it and set a non-zero min_mtu that's the
smallest thing wireguard's xmit semantics will accept. It sounds like
you'd prefer that?

Well, if you believe that wireguard in persistent keepalive
has some value on its own, I guess that we will have to support this mode.

Alright.

quoted

Some legacy devices can have arbitrary mtu, and this has caused headaches.
I was hoping that for brand new devices, we could have saner limits.

About setting max_mtu to ~MAX_INT, does it mean wireguard will attempt
to send UDP datagrams bigger than 64K ? Where is the segmentation done ?

The before passings off to the udp tunnel api, we indicate that we
support ip segmentation, and then it gets handled and fragmented
deeper down. Check out socket.c. 

Okay. Speaking of socket.c, I found this wg_socket_reinit() snippet :

synchronize_rcu();
synchronize_net();

Which makes little sense. Please add a comment explaining why these two
calls are needed.