Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190612035715.166676-1-maowenan@huawei.com> <CANn89iJH6ZBH774SNrd2sUd_A5OBniiUVX=HBq6H4PXEW4cjwQ@mail.gmail.com>
 <6de5d6d8-e481-8235-193e-b12e7f511030@huawei.com> <a674e90e-d06f-cb67-604f-30cb736d7c72@huawei.com>
 <6aa69ab5-ed81-6a7f-2b2b-214e44ff0ada@gmail.com> <52025f94-04d3-2a44-11cd-7aa66ebc7e27@huawei.com>
 <CANn89iKzfvZqZRo1pEwqW11DQk1YOPkoAR4tLbjRG9qbKOYEMw@mail.gmail.com> <7d0f5a21-717c-74ee-18ad-fc0432dfbe33@huawei.com>
In-Reply-To: <7d0f5a21-717c-74ee-18ad-fc0432dfbe33@huawei.com>
From:   Eric Dumazet <edumazet@google.com>
Date:   Fri, 14 Jun 2019 07:25:23 -0700
Message-ID: <CANn89iJW0DHBg=RKgdLq1r33THL15UO3c2n4MkR6DdD7-QwP1w@mail.gmail.com>
Subject: Re: [PATCH net v2] tcp: avoid creating multiple req socks with the
 same tuples
To:     maowenan <maowenan@huawei.com>
Cc:     Eric Dumazet <eric.dumazet@gmail.com>,
        David Miller <davem@davemloft.net>,
        netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 14, 2019 at 7:04 AM maowenan <maowenan@huawei.com> wrote:
> I agree that this is a special case.
> I propose one point about the sequence of synack, if two synack with two different
> sequence since the time elapse 64ns, this issue disappear.
>
> tcp_conn_request->tcp_v4_init_seq->secure_tcp_seq->seq_scale
> static u32 seq_scale(u32 seq)
> {
>         /*
>          *      As close as possible to RFC 793, which
>          *      suggests using a 250 kHz clock.
>          *      Further reading shows this assumes 2 Mb/s networks.
>          *      For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
>          *      For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
>          *      we also need to limit the resolution so that the u32 seq
>          *      overlaps less than one time per MSL (2 minutes).
>          *      Choosing a clock of 64 ns period is OK. (period of 274 s)
>          */
>         return seq + (ktime_get_real_ns() >> 6);
> }
>
> So if the long delay larger than 64ns, the seq is difference.

The core issue has nothing to do with syncookies.

Are you sure you really understand this stack ?