netdev - Re: [PATCH v2 6/7] net-tcp: Fast Open client

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]

Date:	Wed, 18 Jul 2012 23:35:47 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yuchung Cheng <ycheng@...gle.com>
Cc:	davem@...emloft.net, hkchu@...gle.com, edumazet@...gle.com,
	ncardwell@...gle.com, sivasankar@...ucsd.edu,
	netdev@...r.kernel.org
Subject: Re: [PATCH v2 6/7] net-tcp: Fast Open client - detecting SYN-data
 drops

On Wed, 2012-07-18 at 14:01 -0700, Yuchung Cheng wrote:
> On paths with firewalls dropping SYN with data or experimental TCP options,
> Fast Open connections will have experience SYN timeout and bad performance.
> The solution is to track such incidents in the cookie cache and disables
> Fast Open temporarily.
> 
> Since only the original SYN includes data and/or Fast Open option, the
> SYN-ACK has some tell-tale sign (tcp_rcv_fastopen_synack()) to detect
> such drops. If a path has recurring Fast Open SYN drops, Fast Open is
> disabled for 2^(recurring_losses) minutes starting from four minutes up to
> roughly one and half day. sendmsg with MSG_FASTOPEN flag will succeed but
> it behaves as connect() then write().
> 
> Signed-off-by: Yuchung Cheng <ycheng@...gle.com>
...

>  void tcp_fastopen_cache_set(struct sock *sk, u16 mss,
> -			    struct tcp_fastopen_cookie *cookie)
> +			    struct tcp_fastopen_cookie *cookie, bool syn_lost)
>  {
>  	struct tcp_metrics_block *tm;
>  
> @@ -670,6 +675,11 @@ void tcp_fastopen_cache_set(struct sock *sk, u16 mss,
>  		tfom->mss = mss;
>  		if (cookie->len > 0)
>  			tfom->cookie = *cookie;
> +		if (syn_lost) {
> +			++tfom->syn_loss;
> +			tfom->last_syn_loss = jiffies;
> +		} else
> +			tfom->syn_loss = 0;
>  	}
>  	rcu_read_unlock();
>  }

Proably needs a respin after you use a seqlock, otherwise looks good to
me.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html