Backport due to incorrect socket syscall definitions on s390x with Linux 4.3 headers.

  Hi,

Beginning with Linux 4.3, the kernel headers contain direct system call 
numbers __NR_socket etc. on s390x. On older kernels, the 
socket-multiplexer syscall __NR_socketcall was used.

To enable these new syscalls, the patch
"S390: Call direct system calls for socket operations."
(https://sourceware.org/git/?p=glibc.git;a=commit;h=016495b818cb61df7d0d10e6db54074271b3e3a5)
was applied upstream.
If glibc 2.23 is configured with --enable-kernel=4.3 and newer,
the direct socket syscalls are used.
For older kernels, the socket-multiplexer syscall is used.

In glibc 2.22 and earlier, this patch is currently not applied.
If you build glibc on an kernel < 4.3, the socket-multiplexer syscall is 
used. But if you build glibc on kernel >= 4.3, the direct
socket-syscalls are used. If you install this glibc on an
kernel < 4.3, all socket operations will fail.
See "Bug 19682 - s390x: Incorrect syscall definitions cause breakage 
with Linux 4.3 headers" 
(https://sourceware.org/bugzilla/show_bug.cgi?id=19682)
The configure switch --enable-kernel does not influence this behaviour 
on older glibc-releases.

The solution is to remove the direct socket-syscalls in 
sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list (see attached patch) 
on older glibc-releases as it was done by the upstream patch, too. These 
entries were never used on s390x, but the c-files in 
sysdeps/unix/sysv/linux/.
After this removal, the behaviour of the socket functions are not 
changed compared to the original glibc release version and the 
socket-multiplexer-syscall is always used.

Florian Weimer told me, that he already did this for Fedora 23 (glibc 
2.22) and Fedora 22 (glibc 2.21).
Thus, backporting this to glibc branch 2.22, and 2.21 would be the best 
for Fedora.

Which other glibc-branches should be updated???

Please give feedback.

Bye
Stefan

---
ChangeLog:

	* sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list:
	Remove socketcall syscalls.
  

On 25 Feb 2016 16:35, Stefan Liebler wrote:
> Beginning with Linux 4.3, the kernel headers contain direct system call 
> numbers __NR_socket etc. on s390x. On older kernels, the 
> socket-multiplexer syscall __NR_socketcall was used.
> 
> To enable these new syscalls, the patch
> "S390: Call direct system calls for socket operations."
> (https://sourceware.org/git/?p=glibc.git;a=commit;h=016495b818cb61df7d0d10e6db54074271b3e3a5)
> was applied upstream.
> If glibc 2.23 is configured with --enable-kernel=4.3 and newer,
> the direct socket syscalls are used.
> For older kernels, the socket-multiplexer syscall is used.
> 
> In glibc 2.22 and earlier, this patch is currently not applied.
> If you build glibc on an kernel < 4.3, the socket-multiplexer syscall is 
> used. But if you build glibc on kernel >= 4.3, the direct
> socket-syscalls are used. If you install this glibc on an
> kernel < 4.3, all socket operations will fail.
> See "Bug 19682 - s390x: Incorrect syscall definitions cause breakage 
> with Linux 4.3 headers" 
> (https://sourceware.org/bugzilla/show_bug.cgi?id=19682)
> The configure switch --enable-kernel does not influence this behaviour 
> on older glibc-releases.
> 
> The solution is to remove the direct socket-syscalls in 
> sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list (see attached patch) 
> on older glibc-releases as it was done by the upstream patch, too. These 
> entries were never used on s390x, but the c-files in 
> sysdeps/unix/sysv/linux/.
> After this removal, the behaviour of the socket functions are not 
> changed compared to the original glibc release version and the 
> socket-multiplexer-syscall is always used.
> 
> Florian Weimer told me, that he already did this for Fedora 23 (glibc 
> 2.22) and Fedora 22 (glibc 2.21).
> Thus, backporting this to glibc branch 2.22, and 2.21 would be the best 
> for Fedora.
> 
> Which other glibc-branches should be updated???

i would say all branches at least back to glibc-2.20

the Gentoo s390 boxes are on linux-4.4 so it won't impact our releasing,
but would be good to have the releases themselves be OK on older :).
-mike