netdev - Re: [PATCH 2/2] socket: add minimum listen queue length sysctl

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 26 Mar 2011 00:51:01 +0100
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Rick Jones <rick.jones2@...com>
Cc:	netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH 2/2] socket: add minimum listen queue length sysctl

* Rick Jones | 2011-03-25 13:24:37 [-0700]:

Hello Rick

>Well, one could LD_PRELOAD something that intercepted listen() calls no?

Noes, for dynamically linked programs yes, for statically linked ones no.

Furthermore, for distribution shipped programs an administrator would not
alter the init script or something. Editing /etc/sysctl.conf is as simple
as ...

>Is there already a similar minimum the admin can configure when the
>applications makes "too small" an explicit setsockopt() call against
>SO_SNDBUF or SO_RCVBUF?

net.ipv4.tcp_rmem, net.ipv4.tcp_mem, net.core.rmem_default, ...?

IMHO, _if_ a programmer modifies the send or receive buffer he _knows_ exactly
why. If he does not modify the buffer it is fine too, because _we_ tune the
buffers as good as we can - and we are good in this.

But, the backlog is different. Often the programmer does _not_ know how to
tune this variable. And, often the backlog depends on the target system, on
the network characteristic and the like.

Therefore we provide the system administrator the _ability_ to tune the actual
backlog.

Hagen
--
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