* Update SOMAXCONN value from Linux 5.4 @ 2019-11-29 1:10 Joseph Myers 2019-11-29 4:18 ` Carlos O'Donell 2019-11-29 8:32 ` Florian Weimer 0 siblings, 2 replies; 4+ messages in thread From: Joseph Myers @ 2019-11-29 1:10 UTC (permalink / raw) To: libc-alpha 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. 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> -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Update SOMAXCONN value from Linux 5.4 2019-11-29 1:10 Update SOMAXCONN value from Linux 5.4 Joseph Myers @ 2019-11-29 4:18 ` Carlos O'Donell 2019-11-29 8:32 ` Florian Weimer 1 sibling, 0 replies; 4+ messages in thread From: Carlos O'Donell @ 2019-11-29 4:18 UTC (permalink / raw) To: Joseph Myers, libc-alpha 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. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Update SOMAXCONN value from Linux 5.4 2019-11-29 1:10 Update SOMAXCONN value from Linux 5.4 Joseph Myers 2019-11-29 4:18 ` Carlos O'Donell @ 2019-11-29 8:32 ` Florian Weimer 2019-11-29 8:35 ` Florian Weimer 1 sibling, 1 reply; 4+ messages in thread From: Florian Weimer @ 2019-11-29 8:32 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha * 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Update SOMAXCONN value from Linux 5.4 2019-11-29 8:32 ` Florian Weimer @ 2019-11-29 8:35 ` Florian Weimer 0 siblings, 0 replies; 4+ messages in thread From: Florian Weimer @ 2019-11-29 8:35 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha * 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-11-29 8:35 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-29 1:10 Update SOMAXCONN value from Linux 5.4 Joseph Myers 2019-11-29 4:18 ` Carlos O'Donell 2019-11-29 8:32 ` Florian Weimer 2019-11-29 8:35 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).