aboutsummaryrefslogtreecommitdiff
path: root/sysdeps/unix/sysv/linux/sendmmsg.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2019-11-29 14:17:15 +0000
committerJoseph Myers <joseph@codesourcery.com>2019-11-29 14:17:15 +0000
commit96958e2700f5b4f4d1183a0606b2b9848a53ea44 (patch)
treea5b2ab875729ccbf923f61a2d554b92231147295 /sysdeps/unix/sysv/linux/sendmmsg.c
parenta331150af65477fc3fa72ab341eed5e0b2daf7f3 (diff)
downloadglibc-96958e2700f5b4f4d1183a0606b2b9848a53ea44.zip
glibc-96958e2700f5b4f4d1183a0606b2b9848a53ea44.tar.gz
glibc-96958e2700f5b4f4d1183a0606b2b9848a53ea44.tar.bz2
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.
Diffstat (limited to 'sysdeps/unix/sysv/linux/sendmmsg.c')
0 files changed, 0 insertions, 0 deletions