On Wed, Nov 18, 2015 at 8:19 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > I was wondering why you didn't use tcp_close function, because still we > could have the address and we would like to do a proper shutdown of the > connection. While this patchset wants to tear down sockets for addresses > no longer alive, it still can be used with full sockets.
>From the perspective of the TCP state machine, there's not much difference. In most TCP states, tcp_close takes the socket straight to TCP_CLOSE (not into TCP_TIME_WAIT). There is a difference in that tcp_close() sends a RST by calling tcp_send_active_reset. We could make tcp_diag_destroy do that too. Not sure it's worth it because in most of the the cases where you'd want to use SOCK_DESTROY (e.g., you've lost a network connection, a VPN connected, etc.), tcp_send_active_reset is either not going to send a RST at all or it's going send on the wrong network. Even if we're still connected to the same network (e.g., in the case where you're running "ss --kill" to close a socket instead of the bad old days where you had to load your process in gdb and call close() from there :-)), not sending a RST is not the end of the world, because as soon as the peer sends us a packet we'll send a RST anyway. In any case calling tcp_close itself won't work - that's intended for userspace closes. It calls sock_orphan, which nulls out the backpointer to the userspace socket structure, and assumes that there are no userspace references to the protocol socket. If we make SOCK_DESTROY call tcp_close without releasing the userspace components, things blow up as soon as the app calls close(). -- 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
