On (05/04/15 16:21), David Miller wrote: > > No table at all. > > There has to be another way to notice this kind of situation, how > for example does NFS or any other sunrpc using service handle this > case?
NFS fixes up CLOSE_WAIT connections from xs_tcp_state_change, so at the least, I can also do rds_conn_drop from rds_tcp_state_change, that will avoid all the extra baggage around the new hash list. But there's the case of the client disappearing without even sending a FIN, and here NFS seems to recover using a notion of idle-timeout (which applies to all idle peers, not merely the dead ones?) The closest analog of that would be to set up a so_keepalive option on the socket, but that brings in even more heuristics keepcnt, keepintvl, keepidle. Maybe I could set these to be some very generous values for now.. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/