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;
Subject: Re: [PATCH net v2] tcp: avoid creating multiple req socks with the
 same tuples
To:     Eric Dumazet <edumazet@google.com>, maowenan <maowenan@huawei.com>
Cc:     David Miller <davem@davemloft.net>,
        netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
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>
 <CANn89iJW0DHBg=RKgdLq1r33THL15UO3c2n4MkR6DdD7-QwP1w@mail.gmail.com>
From:   Eric Dumazet <eric.dumazet@gmail.com>
Message-ID: <0202f817-bd59-918e-96d5-ddf692f5e140@gmail.com>
Date:   Fri, 14 Jun 2019 07:34:37 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CANn89iJW0DHBg=RKgdLq1r33THL15UO3c2n4MkR6DdD7-QwP1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 6/14/19 7:25 AM, Eric Dumazet wrote:
> 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 ?
> 

Oh well, maybe I should not have answered before my breakfast/coffee.

What I meant to say is that we do not want to fix this problem by working around
the issue you noticed (which leads to RST packets)