netdev - Re: [PATCH] Sysctl interface to UNIX_INFLIGHT_TRIGGER

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] [day] [month] [year] [list]

Message-Id: <20101210.125605.258094157.davem@davemloft.net>
Date:	Fri, 10 Dec 2010 12:56:05 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	pavel@...linux.ru, shanwei@...fujitsu.com, netdev@...r.kernel.org
Subject: Re: [PATCH] Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC v.3

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Fri, 10 Dec 2010 14:04:33 +0100

> Le vendredi 10 décembre 2010 à 15:48 +0300, Pavel Vasilyev a écrit :
>> On 10.12.2010 06:45, Shan Wei wrote:
>> > Pavel Vasilyev wrote, at 12/10/2010 01:26 AM:
>> >> Sysctl interface to UNIX_INFLIGHT_TRIGGER_GC.
>> >> IMHO convenient for testing.
>> >>
>> >> +inflight_trigger_gc - INTEGER
>> >> +	The maximal number of inflight sockets for force garbage collect.
>> >> +
>> >> +	Default: 16000
>> > 
>> > 1) For lower payload and enough memory, it's not necessary to force garbage collection.
>> > So set it to 0, disable gc.
>> 
>> 
>> May be, set default to 2000, and zero to disable
>> 
> 
> zero to disable ?
> 
> Maybe you missed commit 9915672d41273f5b77 intent.
> 
> If you have no limit (like old kernels), you can freeze your machine,
> even if it has terabytes of ram, running a single program, even as a non
> root user.
> 
> When we discussed about the fix, we said a limit was needed, obviously.
> 
> Now you'll have to prove we need to make it a sysctl (yet
> another /proc/sys/net parameter, yet another documentation to add...)
> 
> Even changing default from 16000 to 2000 must be for a valid reason (a
> real use case)

I don't want to add this sysctl.  Exactly because there is no reason
to believe that the current value could even need to be changed by
anyone.

Once a demonstratable need can be proven and shown beyond a shadow
of a doubt, we can consider adding the sysctl.

We have too many damn sysctls as-is.
--
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