Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp3648749ioo; Mon, 30 May 2022 06:48:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQNYTa2wCcoyhFC5vUp6MMLekJuJoRVyX2DXGPCK8IeDTAw0OTxE5TOFBdXKTJXPe9wCAb X-Received: by 2002:a62:a209:0:b0:510:3c47:7888 with SMTP id m9-20020a62a209000000b005103c477888mr56790425pff.14.1653918532099; Mon, 30 May 2022 06:48:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653918532; cv=none; d=google.com; s=arc-20160816; b=oeMKUtvIK35PdjDdngOCO1+f0JN11i/B7zZeBNDotf9d08aBrbCd2AVQNVue/oLkwY nEWB5loc1X4HPQ8dOiH2D+1epxgJ0zyd1m9yoXc4hydME0TgFlGeNisK/h4gZzPTEKW7 kx9lvMxYn+2aSuefs64jf1rYWyPsXb2+TrF0/rgTtf02iUsWevGTv5vLnyi2yUP/lW+I aibQo34u3Vr7U8kH39D9EQuGg2dO7p/RL0vUWzLLF79C0TP06IzWCWrDr+L6CxLpUbKV T3i4SuOqsUDZZ5KZC+mgEEXd2KARqMD4n2uczG34qi9gHHO1hNMydf70Kp8OzKG9ckpE /emQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:dkim-signature; bh=5S2m8mI6dN+sV4sEnoAwSpoVjPh8JTGqTD5gKIzxGgk=; b=Kgs8ptgYiBnTUJHBTdateR5mepTbaLrthdRwpzPsvvzQeMC2Xcvtc0Khekatz+w0aq ShzbeMw3EmTVfzed+T/v4w9qDylZkN1PuCafW51qctfDdaISVE7YKAZNPIdtF9pOHbs9 p88E3egzLzZXIgkZp7X46qiOJJU3NXn6LwHEnFDXfdexB19Ul3IAQrcoQP2MAmeZIOMy SkHU1izhsPPNxPtaR2XbmbFqD9zfeug6zc7LP//jMyqV52fwE+C/NgkJlzgOQUJIho1+ N1zfRfyV/FSsKt3z25oAwAeD2mjvVMk9vn/24y1R9jfTY7NNeOPkjGQ66zEEmKKnmFm0 wMfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=dvv2c6kY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a7-20020a170902900700b001623b7ba910si13688882plp.29.2022.05.30.06.48.38; Mon, 30 May 2022 06:48:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=dvv2c6kY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236447AbiE3NPW (ORCPT + 99 others); Mon, 30 May 2022 09:15:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41616 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236510AbiE3NPN (ORCPT ); Mon, 30 May 2022 09:15:13 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E66230F64; Mon, 30 May 2022 06:15:12 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: usama.anjum) with ESMTPSA id 9D8491F42E59 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1653916510; bh=sEie6GXsRwAWSR4UPX24pvsXPPWCr0i8UxuSQOMqwEs=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=dvv2c6kYLYDSJolgU65XbB33Z60fYRhamY0Tz8WYctFlG2XOi2biD1x8zKubNKCmJ 4Sf7u4ZiX8SGYDLQWwgl0qoYPK/bVj57bDD+tp9plFVMLopTPOaV8dP5cB5J7L96D1 IWJmLskH4VmeyBxx2C6YGxYdjPDTi2wXe/r6zCZ4Pt6Za6AKemf1z2qc/NyNluvgaZ 3TBbdf42gkKaITMFnSZdZzvkTd6ke0ytpt5X46U/Yk1X50vn6X9Fvum7ZFBeCu+tqM imD1UhiA2KlHkHgpL6r/Is5oMn58f6/ti4nYVgMrhzNBPRLaOuPGIX51hrkyFDoupj bs9jRW8XuIUew== Message-ID: <8eb9b438-7018-4fe3-8be6-bb023df99594@collabora.com> Date: Mon, 30 May 2022 18:15:03 +0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Muhammad Usama Anjum Subject: Re: [RFC] EADDRINUSE from bind() on application restart after killing To: Eric Dumazet Cc: usama.anjum@collabora.com, "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , Gabriel Krisman Bertazi , open list , Collabora Kernel ML , Paul Gofman , "open list:NETWORKING [TCP]" , Sami Farin References: <5099dc39-c6d9-115a-855b-6aa98d17eb4b@collabora.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thank you for your reply. On 5/25/22 3:13 AM, Eric Dumazet wrote: > On Tue, May 24, 2022 at 1:19 AM Muhammad Usama Anjum > wrote: >> >> Hello, >> >> We have a set of processes which talk with each other through a local >> TCP socket. If the process(es) are killed (through SIGKILL) and >> restarted at once, the bind() fails with EADDRINUSE error. This error >> only appears if application is restarted at once without waiting for 60 >> seconds or more. It seems that there is some timeout of 60 seconds for >> which the previous TCP connection remains alive waiting to get closed >> completely. In that duration if we try to connect again, we get the error. >> >> We are able to avoid this error by adding SO_REUSEADDR attribute to the >> socket in a hack. But this hack cannot be added to the application >> process as we don't own it. >> >> I've looked at the TCP connection states after killing processes in >> different ways. The TCP connection ends up in 2 different states with >> timeouts: >> >> (1) Timeout associated with FIN_WAIT_1 state which is set through >> `tcp_fin_timeout` in procfs (60 seconds by default) >> >> (2) Timeout associated with TIME_WAIT state which cannot be changed. It >> seems like this timeout has come from RFC 1337. >> >> The timeout in (1) can be changed. Timeout in (2) cannot be changed. It >> also doesn't seem feasible to change the timeout of TIME_WAIT state as >> the RFC mentions several hazards. But we are talking about a local TCP >> connection where maybe those hazards aren't applicable directly? Is it >> possible to change timeout for TIME_WAIT state for only local >> connections without any hazards? >> >> We have tested a hack where we replace timeout of TIME_WAIT state from a >> value in procfs for local connections. This solves our problem and >> application starts to work without any modifications to it. >> >> The question is that what can be the best possible solution here? Any >> thoughts will be very helpful. >> > > One solution would be to extend TCP diag to support killing TIME_WAIT sockets. > (This has been raised recently anyway) I think this has been raised here: https://lore.kernel.org/netdev/ba65f579-4e69-ae0d-4770-bc6234beb428@gmail.com/ > > Then you could zap all sockets, before re-starting your program. > > ss -K -ta src :listen_port > > Untested patch: The following command and patch work for my use case. The socket in TIME_WAIT_2 or TIME_WAIT state are closed when zapped. Can you please upstream this patch? > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c > index 9984d23a7f3e1353d2e1fc9053d98c77268c577e..1b7bde889096aa800b2994c64a3a68edf3b62434 > 100644 > --- a/net/ipv4/tcp.c > +++ b/net/ipv4/tcp.c > @@ -4519,6 +4519,15 @@ int tcp_abort(struct sock *sk, int err) > local_bh_enable(); > return 0; > } > + if (sk->sk_state == TCP_TIME_WAIT) { > + struct inet_timewait_sock *tw = inet_twsk(sk); > + > + refcount_inc(&tw->tw_refcnt); > + local_bh_disable(); > + inet_twsk_deschedule_put(tw); > + local_bh_enable(); > + return 0; > + } > return -EOPNOTSUPP; > } -- Muhammad Usama Anjum