netdev - Re: [PATCH RFC] net: decrease the length of backlog queue immediately after it's detached from sk

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, 30 Mar 2016 06:47:17 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yang Yingliang <yangyingliang@...wei.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH RFC] net: decrease the length of backlog queue
 immediately after it's detached from sk

On Wed, 2016-03-30 at 13:56 +0800, Yang Yingliang wrote:

> Sorry, I made a mistake. I am very sure my kernel has these two patches.
> And I can get some dropping of the packets in 10Gb eth.
> 
> # netstat -s | grep -i backlog
>      TCPBacklogDrop: 4135
> # netstat -s | grep -i backlog
>      TCPBacklogDrop: 4167

Sender will retransmit and the receiver backlog will lilely be emptied
before the packets arrive again.

Are you sure these are TCP drops ?

Which 10Gb NIC is it ? (ethtool -i eth0)

What is the max size of sendmsg() chunks are generated by your apps ?

Are they forcing small SO_RCVBUF or SO_SNDBUF ?

What percentage of drops do you have ?

Here (at Google), we have less than one backlog drop per billion
packets, on host facing the public Internet.

If a TCP sender sends a burst of tiny packets because it is misbehaving,
you absolutely will drop packets, especially if applications use
sendmsg() with very big lengths and big SO_SNDBUF.

Trying to not drop these hostile packets as you did is simply opening
your host to DOS attacks.

Eventually, we should even drop earlier in TCP stack (before taking
socket lock).