Bug 1417205

Summary:	Missing AF_VSOCK <sys/socket.h> constant
Product:	Red Hat Enterprise Linux 7	Reporter:	Stefan Hajnoczi <stefanha>
Component:	glibc	Assignee:	Florian Weimer <fweimer>
Status:	CLOSED ERRATA	QA Contact:	Sergey Kolosov <skolosov>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	areis, ashankar, bniver, codonell, fweimer, mnewsome, pfrankli, skolosov, ssaha, stefanha
Target Milestone:	rc	Keywords:	Patch
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glibc-2.17-170.el7	Doc Type:	Enhancement
Doc Text:	glibc now provides definitions for the AF_VSOCK, PF_VSOCK, and TCP_TIMESTAMP constants. These definitions correspond to features in the current Red Hat Enterprise Linux 7 kernel.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 18:09:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1413146

Description Stefan Hajnoczi 2017-01-27 14:23:54 UTC

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>
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

Comment 1 Florian Weimer 2017-01-27 14:30:12 UTC

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.

Comment 2 Carlos O'Donell 2017-01-27 16:49:37 UTC

(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.

Comment 6 Sayan Saha 2017-02-03 14:09:38 UTC

Agree with Brett's statement above. We need this in RHEL 7.4.

Comment 14 errata-xmlrpc 2017-08-01 18:09:25 UTC

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