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;
MIME-Version: 1.0
References: <20230606064306.9192-1-duanmuquan@baidu.com> <CANn89iKwzEtNWME+1Xb57DcT=xpWaBf59hRT4dYrw-jsTdqeLA@mail.gmail.com>
 <DFBEBE81-34A5-4394-9C5B-1A849A6415F1@baidu.com> <CANn89iLm=UeSLBVjACnqyaLo7oMTrY7Ok8RXP9oGDHVwe8LVng@mail.gmail.com>
 <D8D0327E-CEF0-4DFC-83AB-BC20EE3DFCDE@baidu.com> <CANn89iKXttFLj4WCVjWNeograv=LHta4erhtqm=fpfiEWscJCA@mail.gmail.com>
 <8C32A1F5-1160-4863-9201-CF9346290115@baidu.com> <CANn89i+JBhj+g564rfVd9gK7OH48v3N+Ln0vAgJehM5xJh32-g@mail.gmail.com>
 <7FD2F3ED-A3B5-40EF-A505-E7A642D73208@baidu.com> <CANn89iJ5kHmksR=nGSMVjacuV0uqu5Hs0g1s343gvAM9Yf=+Bg@mail.gmail.com>
 <FD0FE67D-378D-4DDE-BB35-6FFDE2AD3AA5@baidu.com> <CANn89iK1yo6R4kZneD_1OZYocQCWp1sxviYzjJ+BBn4HeFSNhw@mail.gmail.com>
 <AF8804B1-D096-4B80-9A1F-37FA03B04123@baidu.com>
In-Reply-To: <AF8804B1-D096-4B80-9A1F-37FA03B04123@baidu.com>
From:   Eric Dumazet <edumazet@google.com>
Date:   Tue, 20 Jun 2023 10:44:08 +0200
Message-ID: <CANn89i+fNWbRLYx7gvF7q_AGdQOhRxgFnwMqnpZK91kkEEg=Uw@mail.gmail.com>
Subject: Re: [PATCH v2] tcp: fix connection reset due to tw hashdance race.
To:     "Duan,Muquan" <duanmuquan@baidu.com>
Cc:     "davem@davemloft.net" <davem@davemloft.net>,
        "dsahern@kernel.org" <dsahern@kernel.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jun 20, 2023 at 5:30=E2=80=AFAM Duan,Muquan <duanmuquan@baidu.com> =
wrote:
>
> Hi, Eric,
>
> Thanks for your comments!
>
> Why not speak of the FIN:
> For current implementation, hashdance can be done on state FIN_WAIT2,  it=
 may race with the ehash lookup process of  passive closer=E2=80=99s FIN. M=
y new patch 3 does the tw hashdance until receiving passive closer's FIN(re=
al TIME_WAIT),  so this race does not exist and  the 'connection refused' i=
ssue will not occur, so I did not speak of the FIN again with the new patch=
.
>
shdance begins, the FIN may be dropped in further process if the sock
is destroyed on another CPU after hashdance.
>
> I took a look at FreeBSD, it uses hash table lock and per sock level lock=
.It also needs some tricks to retry for some cases, for example, sock dropp=
ed by another thread when waiting for per sock lock during the lookup:
>    /*
>      * While waiting for inp lock during the lookup, another thread
>      * can have dropped the inpcb, in which case we need to loop back
>      * and try to find a new inpcb to deliver to.
>      */
>     if (inp->inp_flags & INP_DROPPED) {
>         INP_WUNLOCK(inp);
>         inp =3D NULL;
>         goto findpcb;
> }
>

This is the last time you bring FreeBSD code here.

We do not copy FreeBSD code for obvious reasons.
I never looked at FreeBSD code and never will.

Stop this, please, or I will ignore your future emails.