From: Hannes Frederic Sowa <han...@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_. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
