netdev - Re: [PATCH] Add a sysctl to allow TCP window shrinking in order to honor memory limits

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: Mon, 5 Jun 2023 15:44:30 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Mike Freemon <mfreemon@...udflare.com>
Cc: netdev@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: [PATCH] Add a sysctl to allow TCP window shrinking in order to
 honor memory limits

On Mon, 5 Jun 2023 15:42:29 -0700
Stephen Hemminger <stephen@...workplumber.org> wrote:

> > sysctl: net.ipv4.tcp_shrink_window
> > 
> > This sysctl changes how the TCP window is calculated.
> > 
> > If sysctl tcp_shrink_window is zero (the default value), then the
> > window is never shrunk.
> > 
> > If sysctl tcp_shrink_window is non-zero, then the memory limit
> > set by autotuning is honored.  This requires that the TCP window
> > be shrunk ("retracted") as described in RFC 1122.
> > 
> > [1] https://www.rfc-editor.org/rfc/rfc7323#appendix-F
> > [2] https://www.rfc-editor.org/rfc/rfc7323#section-2.4
> > [3] https://www.rfc-editor.org/rfc/rfc1122#page-91
> > [4] https://www.rfc-editor.org/rfc/rfc793
> > [5] https://www.rfc-editor.org/rfc/rfc1323
> > 
> > Signed-off-by: Mike Freemon <mfreemon@...udflare.com>  
> 
> Does Linux TCP really need another tuning parameter?
> Will tests get run with both feature on and off?
> What default will distributions ship with?
> 
> Sounds like unbounded receive window growth is always a bad
> idea and a latent bug.

FYI - I worked in an environment where every bug fix had to have
a tuning parameter to turn it off. It was a bad idea, driven by
management problems with updating. The number of knobs lead
to confusion and geometric growth in possible code paths.