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]
Message-ID: <20110325235101.GA2641@hell>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ