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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Tue, 6 Jun 2023 17:33:02 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Mike Freemon <mfreemon@...udflare.com>
Cc: Jason Xing <kerneljasonxing@...il.com>, 
	Stephen Hemminger <stephen@...workplumber.org>, Neal Cardwell <ncardwell@...gle.com>, 
	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 Tue, Jun 6, 2023 at 5:17 PM Mike Freemon <mfreemon@...udflare.com> wrote:
>
>
> On 6/5/23 21:09, Jason Xing wrote:
> > On Tue, Jun 6, 2023 at 6:44 AM Stephen Hemminger
> > <stephen@...workplumber.org> wrote:
> >>
> >> 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.
> >>
> >
> > I agree. More than this, shrinking window prohibited in those classic
> > RFCs could cause unexpected/unwanted behaviour.
>
> I discuss the RFCs in more detail in my blog post here:
> https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/

Mike, the usual process to push linux patches is to make them self contained.

changelog should be enough, no need to read a lengthy blog post.

Also, I did not receive a copy of the patch, which is unfortunate,
given I am the linux TCP maintainer.

Next time you post it, make sure to CC me.

Thanks.