From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 807A5C43381 for ; Thu, 21 Feb 2019 15:18:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4EA6720842 for ; Thu, 21 Feb 2019 15:18:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="JRu6r+Tc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728255AbfBUPSJ (ORCPT ); Thu, 21 Feb 2019 10:18:09 -0500 Received: from mail-yw1-f65.google.com ([209.85.161.65]:44331 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbfBUPSJ (ORCPT ); Thu, 21 Feb 2019 10:18:09 -0500 Received: by mail-yw1-f65.google.com with SMTP id x21so10800752ywx.11 for ; Thu, 21 Feb 2019 07:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Egk5pXf6vr1ZMP8XTAPlkHz8M43Lnyzc9EG3ZJ4pVy8=; b=JRu6r+TcD0n+LQfYniXJ80TzN+GZOY6sN35GMmaNam26I+4cFBDC8KRrJ6dRngQf94 ZPLA8ei9WIg9cYicq+AZsXyNPGVssad+f8QhHavHuKVAKmCMKruzhs9KH+1NK4yNqgen 9mm79pHkR0/QwDb+GYOXi+pFrcGbM1RvZHhSljM8rkKEQY+IDmP1DCSJT+PiJhw4d2CD UTYAVCRdqlEt4zZVaCaJ1BBKc7OUHNT4wRmw6UyUO0V9JEjdJtAYClvQqV8MaqsAxF0A v2jLEQlDhs4s9rdbEQH55P3ajLNG66uQG9yEODgFLGVvPdgvsHUBMHdqwisxvDFdDFYE dxJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Egk5pXf6vr1ZMP8XTAPlkHz8M43Lnyzc9EG3ZJ4pVy8=; b=uMGONym5g83N4xWCX5Aqort3m7cHR+31jCjJ1dGADLnvYk01z+YxzSmLQhSUFgs0Vo 2qiPmI76m6YqDJJiKY0YYYvvylPCrc48XIKrgyN5uj4toHF8uhO3QyRZu69CEtFgkSMk UmvDVwmyzOYjGQVOSd+BWYwv8bjXR8bHsWatO4iisW9R7IaSN1C/pZTN2yagB55+aMUP T1svjxy0bfa9zq5kH347yymITO2qYm3+O6yPchKriUmQrGrsLc9w7j9qICuOXfOxk7yy FbfI9Gz9eqEHPODV9ebJ8fKRiDmP9NdC760GD3tadGyi80+0l213tCTQ2mDx+8eyfobN A4sg== X-Gm-Message-State: AHQUAuav8kUCREQICPjPjj1y5XM42RtK9OHrx6f+paaBDD/5jbzwtITK jq/WJVbn65yqiG1RcaWRjDscJibwozO1FOZJXCuQQV23lU4= X-Google-Smtp-Source: AHgI3IZH1USyWC1ZP6AH5VHe5DXVSuQfYm18RxiRuk0lLepT+Y1YyeK5AXX95K0d3GUqaL2oh9LKMYTLH4aie/y5Xq4= X-Received: by 2002:a81:a4d3:: with SMTP id b202mr32814856ywh.83.1550762287489; Thu, 21 Feb 2019 07:18:07 -0800 (PST) MIME-Version: 1.0 References: <20190220142754.GA5073@dendluri-linux.qualcomm.com> <20190221110118.GA24747@dendluri-linux.qualcomm.com> In-Reply-To: <20190221110118.GA24747@dendluri-linux.qualcomm.com> From: Eric Dumazet Date: Thu, 21 Feb 2019 07:17:55 -0800 Message-ID: Subject: Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state To: Devi Sandeep Endluri V V Cc: netdev , subashab@codeaurora.org, sharathv@codeaurora.org, ssaha@codeaurora.org, stranche@codeaurora.org Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Feb 21, 2019 at 3:01 AM Devi Sandeep Endluri V V wrote: > > On Wed, Feb 20, 2019 at 07:47:59AM -0800, Eric Dumazet wrote: > > On Wed, Feb 20, 2019 at 6:28 AM Devi Sandeep Endluri V V > > wrote: > > > > > > Userspace sends tcp connection (sock) destroy on network permission > > > change. Kernel though doesn't send reset for the connections in > > > SYN-SENT state and these connections continue to remain. Even as > > > per RFC 793, there is no hard rule to not send RST on ABORT in > > > this state. Change to make sure RST are send for connections in > > > syn-sent state to avoid lingering connections on network switch. > > > > > > References from RFC 793 > > > > > > ABORT Call > > > > > > SYN-SENT STATE > > > > > > All queued SENDs and RECEIVEs should be given "connection reset" > > > notification, delete the TCB, enter CLOSED state, and return. > > > > > > SEGMENT ARRIVES > > > > > > If the state is SYN-SENT then > > > If the RST bit is set > > > > > > If the ACK was acceptable then signal the user "error: > > > connection reset", drop the segment, enter CLOSED state, > > > delete TCB, and return. Otherwise (no ACK) drop the segment > > > and return. > > > > > > Signed-off-by: Devi Sandeep Endluri V V > > > --- > > > net/ipv4/tcp.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git net/ipv4/tcp.c net/ipv4/tcp.c > > > index cf3c509..8569dc5e 100644 > > > --- net/ipv4/tcp.c > > > +++ net/ipv4/tcp.c > > > @@ -2495,7 +2495,7 @@ static inline bool tcp_need_reset(int state) > > > { > > > return (1 << state) & > > > (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_FIN_WAIT1 | > > > - TCPF_FIN_WAIT2 | TCPF_SYN_RECV); > > > + TCPF_FIN_WAIT2 | TCPF_SYN_RECV | TCPF_SYN_SENT); > > > } > > > > > > static void tcp_rtx_queue_purge(struct sock *sk) > > > > Hi > > > > 1) I do not believe this patch is complete : > > You have not changed tcp_disconnect() which seems to have dead code > > if we apply your patch. > > > > 2) I am not sure we want to send yet another packet if the prior SYN > > packets elect no answer. > > (It is not clear if your patch applies to this case) > > > > 3) If we do not RESET, the other side has not seen the 3rd packet and > > should eventually exit from SYN_RECV state and die. > > > > 4) A RESET can be lost on the network, and nothing will retransmit it. > > > > Can you describe the use case more precisely, because it seems in > > contradiction of a feature that we plan to upstream. > > (TCP_SILENT_CLOSE : do not send flood of RST/FIN when a gigantic > > server process prematurely dies) > > > > Thanks. > > The algorithm for our network switch needs to have all TCP sessions > on the previous network cleaned up. So, we are trying to reset the > connections in SYN-SENT state as well. Is there any other way to > forcefully reset these connections immediately rather than waiting > for the other side to eventually exit and die? There is no way we can make sure all TCP sessions are cleaned up. For example, we can not make sure no machine eventually crashes or is unexpectedly powered down. What is the "algorithm for your network switch" exactly. Sorry, I am not convinced we want to add more RST packets on the network, most SRE closely look at RST packets as some proxy of 'badness'.