Re: Add a SOCK_DESTROY operation to close sockets from userspace

[David Miller <davem@davemloft.net>]

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 18 Nov 2015 21:43:36 +0100

> Basically my concern is the same one I tried to express in the other
> patch about Florian's patch "[PATCH -next] net: tcp: move to
> timewait when receiving data post active-close": we could give the
> socket back way too early so the quadruple can be reused. If
> timestamps are not in use or we are dealing with NAT were we have
> dozens of synchronized clocks behind the masquerading device, we
> could end up in accepting delayed data. Especially this scenario can
> come up when the address is actually not released but someone uses
> this feature on a server.

Ok, these are legitimate concerns.

What if we implemented this the other way.  The operations that make
the sockets no longer connected to the world, close them.  The route
delete during address removal does the socket scan and then the done
calls on those sockets.

Likewise a VPN or network realm/namespace configuration change can do
similarly.

That way we are guaranteed to only tcp_done() these sockets strictly
in situations where we know that they have been fully disconnected
from the network.

The more I think about it more the more I agree with him and dislike
having user space make sure "it's ok", that isn't where TCP protocol
semantic rules are implemented.  It belongs in the kernel.

Whether we do this or not, that's the policy part and userland can
therefore tell us what it wants when it removes addresses or whatever.

But userland should not be doing the socket scan and triggering the
closes, _no_ _way_.