Re: [PATCH] Revert "net: limit tcp/udp rmem/wmem to SOCK_{RCV,SND}BUF_MIN"

[David Miller]

From: Calvin Owens <calvinowens@xxxxxx>
Date: Thu, 13 Aug 2015 14:21:34 -0700

> Commit 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to
> SOCK_{RCV,SND}BUF_MIN") modified four sysctls to enforce that the values
> written to them are not less than SOCK_MIN_{RCV,SND}BUF.
> 
> That change causes 4096 to no longer be accepted as a valid value for
> 'min' in tcp_wmem and udp_wmem_min. 4096 has been the default for both
> of those sysctls for a long time, and unfortunately seems to be an
> extremely popular setting. This change breaks a large number of sysctl
> configurations at Facebook.
> 
> That commit referred to b1cb59cf2efe7971 ("net: sysctl_net_core: check
> SNDBUF and RCVBUF for min length"), which choose to use the SOCK_MIN
> constants as the lower limits to avoid nasty bugs. But AFAICS, a limit
> of SOCK_MIN_SNDBUF isn't necessary to do that: the BUG_ON cited in the
> commit message seems to have happened because unix_stream_sendmsg()
> expects a minimum of a full page (ie SK_MEM_QUANTUM) and the math broke,
> not because it had less than SOCK_MIN_SNDBUF allocated.
> 
> This particular issue doesn't seem to affect TCP however: using a
> setting of "1 1 1" for tcp_{r,w}mem works, although it's obviously
> suboptimal. SK_MEM_QUANTUM would be a nice minimum, but it's 64K on
> some archs, so there would still be breakage.
> 
> Since a value of one doesn't seem to cause any problems, we can drop the
> minimum 8133534c added to fix this.
> 
> This reverts commit 8133534c760d4083f79d2cde42c636ccc0b2792e.
> 
> Fixes: 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to SOCK_MIN...")
> Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>
> Cc: Sorin Dumitru <sorin@xxxxxxxxxxx>
> Signed-off-by: Calvin Owens <calvinowens@xxxxxx>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/