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=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 0C54CC43381 for ; Thu, 21 Feb 2019 11:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C6B3F20855 for ; Thu, 21 Feb 2019 11:01:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="Zr19zYHQ"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="iELJZnFj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726389AbfBULBk (ORCPT ); Thu, 21 Feb 2019 06:01:40 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:53848 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725814AbfBULBk (ORCPT ); Thu, 21 Feb 2019 06:01:40 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 01ADE60716; Thu, 21 Feb 2019 11:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1550746899; bh=qQ/mrNS29ky15JxmMjqI/J8LenXvj0IR+eE2hFzPLv4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Zr19zYHQfeA2UfLcMd27JJy88eel0zugb7i1YHv5wx+wuisclXAc/FpIH5xU3Xdpg c3qJqohYrWaqsSNbKdWqJeoOLVJdsFY/B59suJKxY+Bio/MAzVIf4MqfdmMmAIAY5S MS6odIcwz4tGWZhsb0ce3AHUgs02qRyyFqxPrlSY= Received: from dendluri-linux.qualcomm.com (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dendluri@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A76E360918; Thu, 21 Feb 2019 11:01:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1550746897; bh=qQ/mrNS29ky15JxmMjqI/J8LenXvj0IR+eE2hFzPLv4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iELJZnFjj11NPieX+D/17IOX/9sAomyVdZuztTgjpcRcaXQxboPGbkWwPl9EU7Idq 0cAxAQ5nyjorRA/8uVyCuyfVl4NfcOCYfEmd+kGTfXllvDKxF58PLo99WNTvdB8v9C 4gaTFLNzZJ9VOmdFIk1SBidCCFSviUOMTnCmVxnU= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A76E360918 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=dendluri@codeaurora.org Date: Thu, 21 Feb 2019 16:31:20 +0530 From: Devi Sandeep Endluri V V To: Eric Dumazet Cc: netdev , subashab@codeaurora.org, sharathv@codeaurora.org, ssaha@codeaurora.org, stranche@codeaurora.org Subject: Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state Message-ID: <20190221110118.GA24747@dendluri-linux.qualcomm.com> References: <20190220142754.GA5073@dendluri-linux.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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?