On Thu, Nov 19, 2015 at 2:33 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2015-11-19 at 14:14 -0800, Tom Herbert wrote: >> On Thu, Nov 19, 2015 at 2:07 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> > On Thu, 2015-11-19 at 13:53 -0800, Tom Herbert wrote: >> > >> >> That covers the case where the local address is removed, but the not >> >> the case where the network manager is informed of an error in the path >> >> and wants to signal the application. My understanding was that >> >> SIOCKILLADDR would work for the first case, but this patch was need to >> >> cover the second case. >> >> >> >> btw, instead of closing the TCP socket can we just report an error and >> >> wake up the application without affecting the connection? That is this >> >> just becomes an error on the socket. The response by the application >> >> will be the same in any case, porbablly just close the socket and try >> >> to reestablish the connection. >> > >> > I thought this was the patch intent ? >> > >> > Application gets a EPOLLIN|EPOLLOUT|POLLERR notification (if it is >> > willing to receive it, or blocked in a socket syscall) and closes the >> > socket. >> > >> > sk->sk_err = ETIMEDOUT; >> > sk->sk_error_report(sk); >> > tcp_done(sk); >> > >> The tcp_done is not needed here. This is the difference between the >> application having the connection closed underneath them, versus the >> application performing a close to terminate the connection. The latter >> behavior preserves the semantics that only the stack or the >> application owning the socket can initiate a state change on the >> connection. > > > The code behaves like we received a formal RST : > But we didn't get a RST, closing the connection is not being done under the auspices of the protocol. The most comparable event to be a timeout on the socket read operation.
> Please do not even bother trying to send additional data, it is not > worth wasting precious resource. > It is reasonable to think of this mechanism as way to indicate loss of reachability. But if this is being viewed as a way to do resource management that is a little worrisome. What is to stop someone from using this mechanism from implementing to implement a security layer, or imposing a global time limit to how long someone can be connected, or to start killing connections based on some arbitrary policy when under memory pressure. I am not necessarily saying this stuff is necessarily bad or an abuse of the mechanism, but the flexibility and power of the mechanism opens the door for these use cases. Tom -- 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
