| 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
| ||
|
Message-ID: <1300622144.2831.287.camel@edumazet-laptop> Date: Sun, 20 Mar 2011 12:55:44 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Hagen Paul Pfeifer <hagen@...u.net> Cc: netdev@...r.kernel.org Subject: Re: [PATCH] socket: increase default maximum listen queue length Le dimanche 20 mars 2011 à 12:39 +0100, Hagen Paul Pfeifer a écrit : > * Eric Dumazet | 2011-03-20 09:30:17 [+0100]: > > >Hmm, real problem is not the 'maximum queue value', but the minimum one. > > > >If application says : listen(fd, 10), you are stuck. > > > >128 or 256 is way too small on some servers, where admin can tune > >in /etc/sysctl.conf : > > > >net.core.somaxconn = 8192 > >net.ipv4.tcp_max_syn_backlog = 8192 > > > >But application also needs to use : listen(fd, 8192) > > I know Eric, I wrote the patch. ;-) The used naming goes like this: > > The system limits (somaxconn & tcp_max_syn_backlog) specify a _maximum_, the > user cannot exceed this limit with listen(2). The backlog argument for listen > on the other hand specify a _minimum_. But the patch increased the default > maximum, therefore I named it in this way. I am not sure you understood what I said. Even if you change kernel limits, many applications still use low limits : listen(fd, 8) I remember some other OS (was it HPUX or Solaris...) had a minimum limit : Even if application said 8, an admin could impose a 256 value for example. Frankly, I believe somaxconn should be a default enforcement, that a particular protocol could override. TCP sockets for example should only enforce tcp_max_syn_backlog limit, not the somaxconn & tcp_max_syn_backlog. -- 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