Hello, On Wed, Nov 18, 2015, at 14:04, Lorenzo Colitti wrote: > 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).
Active close will end up in time wait in the end anyway (with some exceptions). > 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. Ack. I don't think it makes sense to provide a FIN/RST less way of closing a socket, just invoke a shutdown() from an interface might be okayish IMHO. > 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(). I was not saying using tcp_close literally, sorry for not making that clear, but just model the state transitions after tcp_close. At least it seems like a normal close to me. Thanks, Hannes -- 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
