netdev - RE: [PATCH V2 2/7] tcp: use limited socket backlog

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: <DA586906BA1FFC4384FCFD6429ECE860A45A6D9E@shzsmsx502.ccr.corp.intel.com>
Date:	Thu, 4 Mar 2010 19:04:55 +0800
From:	"Zhu, Yi" <yi.zhu@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	"Pekka Savola (ipv6)" <pekkas@...core.fi>,
	Patrick McHardy <kaber@...sh.net>
Subject: RE: [PATCH V2 2/7] tcp: use limited socket backlog

Eric Dumazet <eric.dumazet@...il.com> wrote:

>> Can you show me where sk_drops is used by TCP and what SNMP MIB value
>> should I use for backlog dropping? TCP_MIB_INERRS doesn't seem correct.

> sk_drop is not yet used by TCP, because when backlog processing is
> performed, TCP state machine has much finer grain capabilities to show
> why a packet is dropped. In our backlog drop, we dont examine details of
> packet and drop it at a lower level.

> Please add a new counter, say LINUX_MIB_TCPBACKLOGDROP :

> 3 added lines:
> - one in "include/linux/snmp.h" to define the MIB name
> - one to define its string
> - one to perform the increment when actual drop occurs)

> A good starting point would be to study recent commit
> 72032fdbcde8b333e65b3430e1bcb4358e2d6716 from Jamal
> (xfrm: Introduce LINUX_MIB_XFRMFWDHDRERROR)

> For sk_drop, just increment it and we can get it at generic sock level.

Since neither sk_drops nor the new MIB value are used by TCP currently.
How about I keep the tcp backlog limit patch as is and you implement
the above in another patch?

Thanks,
-yi