netdev - Re: resend: tcp: performance issue with fastopen connections (mss

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dbbcda8-ce79-641c-cf3b-21f41c563939@oracle.com>
Date:   Wed, 18 Jan 2017 20:32:51 +0300
From:   Alexey Kodanev <alexey.kodanev@...cle.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Vasily Isaenko <vasily.isaenko@...cle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: resend: tcp: performance issue with fastopen connections (mss >
 window)

Hi Eric,

On 01/13/2017 08:07 PM, Alexey Kodanev wrote:

> Hi Eric,
> On 13.01.2017 18:35, Eric Dumazet wrote:
>
>> I would suggest to clamp MSS to half the initial window, but I guess
>> this is impractical since window in SYN/SYNACK are not scaled.

Looks like max_window not correctly initialized for tfo sockets.
On my test machine it has set to '5592320' in tcp_fastopen_create_child().

This diff fixes the issue, the question: is this the right place to do it?

diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 4e777a3..33ed508 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -206,6 +206,8 @@ static struct sock *tcp_fastopen_create_child(struct 
sock *sk,
          */
         tp->snd_wnd = ntohs(tcp_hdr(skb)->window);

+       tp->max_window = tp->snd_wnd;
+
         /* Activate the retrans timer so that SYNACK can be retransmitted.
          * The request socket is not added to the ehash
          * because it's been added to the accept queue directly.


Thanks,
Alexey