Update SOMAXCONN value from Linux 5.4

Linux 5.4 changes the SOMAXCONN value from 128 to 4096 (this isn't in
a uapi header; various constants related to the kernel/userspace
interface, including this one, are in the non-uapi linux/socket.h
header).

This patch increases the value in glibc.  As I understand it, it is
safe to use a higher value even with older kernels (the kernel will
simply adjust the value passed to listen to be no more than the value
supported in the kernel), and SOMAXCONN is actually only a default for
a sysctl value in the kernel that can be changed at runtime.  So I
think updating the value in glibc is a reasonable and safe thing to
do.

Tested for x86_64.

On 11/28/19 8:10 PM, Joseph Myers wrote:
> Linux 5.4 changes the SOMAXCONN value from 128 to 4096 (this isn't in
> a uapi header; various constants related to the kernel/userspace
> interface, including this one, are in the non-uapi linux/socket.h
> header).

I reviewed linux 5.4 and indeed SOMAXCONN is now 4096.

It controls, via prctl, the socket listen backlog, and it's completely
configurable, so it's not an ABI in any concrete way.

For example listen(fd, -1) is supposed to use the kernel's maximum
value for SOMAXCONN (though that's not what POSIX says it should do,
but the kernel code below does that with the (unsigned int) cast).

Specifying a backlog greater than the kernel's value should truncate
to that value, which means that raising it in userspace is fine for
old kernels (where it will be truncated to 128).

e.g.
linux/net/socket.c:
1677                 if ((unsigned int)backlog > somaxconn)
1678                         backlog = somaxconn;

Any two parts of an application assuming the same value for SOMAXCONN
would be broken by this change though, so we will have to keep an eye
out for that. The only reasonable use is as a parameter to listen,
though it might have been used for something else and you can't easily
control that.

> This patch increases the value in glibc.  As I understand it, it is
> safe to use a higher value even with older kernels (the kernel will
> simply adjust the value passed to listen to be no more than the value
> supported in the kernel), and SOMAXCONN is actually only a default for
> a sysctl value in the kernel that can be changed at runtime.  So I
> think updating the value in glibc is a reasonable and safe thing to
> do.

Agreed.

OK for master.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

> Tested for x86_64.
> 
> diff --git a/sysdeps/unix/sysv/linux/bits/socket.h b/sysdeps/unix/sysv/linux/bits/socket.h
> index 3e88d66328..7537a7e86b 100644
> --- a/sysdeps/unix/sysv/linux/bits/socket.h
> +++ b/sysdeps/unix/sysv/linux/bits/socket.h
> @@ -169,7 +169,7 @@ typedef __socklen_t socklen_t;
>  #define SOL_XDP		283
>  
>  /* Maximum queue length specifiable by listen.  */
> -#define SOMAXCONN	128
> +#define SOMAXCONN	4096
>  
>  /* Get the definition of the macro to define the common sockaddr members.  */
>  #include <bits/sockaddr.h>
> 

Note: You didn't write [PATCH] in your subject line, so I wasn't
sure if you wanted review for this, but I provided it anyway like
Florian and Dmitry did for your other patches.

* Joseph Myers:

> Linux 5.4 changes the SOMAXCONN value from 128 to 4096 (this isn't in
> a uapi header; various constants related to the kernel/userspace
> interface, including this one, are in the non-uapi linux/socket.h
> header).
>
> This patch increases the value in glibc.  As I understand it, it is
> safe to use a higher value even with older kernels (the kernel will
> simply adjust the value passed to listen to be no more than the value
> supported in the kernel), and SOMAXCONN is actually only a default for
> a sysctl value in the kernel that can be changed at runtime.  So I
> think updating the value in glibc is a reasonable and safe thing to
> do.

Should we add a deprecation warning to the macro and eventually remove
it, given that it's not actually a constant?

* Florian Weimer:

> * Joseph Myers:
>
>> Linux 5.4 changes the SOMAXCONN value from 128 to 4096 (this isn't in
>> a uapi header; various constants related to the kernel/userspace
>> interface, including this one, are in the non-uapi linux/socket.h
>> header).
>>
>> This patch increases the value in glibc.  As I understand it, it is
>> safe to use a higher value even with older kernels (the kernel will
>> simply adjust the value passed to listen to be no more than the value
>> supported in the kernel), and SOMAXCONN is actually only a default for
>> a sysctl value in the kernel that can be changed at runtime.  So I
>> think updating the value in glibc is a reasonable and safe thing to
>> do.
>
> Should we add a deprecation warning to the macro and eventually remove
> it, given that it's not actually a constant?

Oh, I see: POSIX assumes that the implementation uses a constant value
for the queue length and requires us to define the macro.