Red Hat Bugzilla – Bug 1417205
Missing AF_VSOCK <sys/socket.h> constant
Last modified: 2017-08-01 14:09:25 EDT
Description of problem: bz#1291282 adds the virtio-vsock kernel drivers. The AF_VSOCK constant that applications need for this new feature is provided by the glibc-headers package /usr/include/bits/socket.h header file. The following glibc 2.18 commit is missing downstream: commit 164fd39d05925717e75715929c7ced14a2c1505e Author: Andreas Jaeger <aj@suse.de> Date: Fri May 3 20:51:27 2013 +0200 Sync with Linux 3.9 * sysdeps/gnu/netinet/tcp.h (TCP_TIMESTAMP): New value, from Linux 3.9. * sysdeps/unix/sysv/linux/bits/socket.h (PF_VSOCK, AF_VSOCK): Add. (PF_MAX): Adjust for VSOCK change. As noted in the commit message, it also defines TCP_TIMESTAMP. The kernel code for TCP_TIMESTAMP exists downstream so it seems reasonable to backport this commit wholesale. Actual results: $ grep -c AF_VSOCK /usr/include/bits/socket.h 0 Expected results: $ grep -c AF_VSOCK /usr/include/bits/socket.h 1
We have not changed the value of PF_MAX in a y-stream release before, so I'm slightly worried by the upstream patch. On the other hand, I have not heard anything about problems from such changes upstream.
(In reply to Florian Weimer from comment #1) > We have not changed the value of PF_MAX in a y-stream release before, so I'm > slightly worried by the upstream patch. > > On the other hand, I have not heard anything about problems from such > changes upstream. Yes, we have never changed a value like PF_MAX in a y-stream release before. It could lead to a mismatch between library and application expectations. However, given that PF_MAX grows with each addition of a new AF_* entry it would seem less than robust for an application to assume a PF_MAX value and use that to size an array passed to a library compiled with a different PF_MAX value. The other scenario is code that refuses to use the new value because it is larger than the old PF_MAX it knows about, and that's OK. That's a plausible safeguard against unknown AF_* values. We have incremented PF_MAX in upstream and I have also never seen a problem upstream for this.
Agree with Brett's statement above. We need this in RHEL 7.4.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1916