Bug 1417205 - Missing AF_VSOCK <sys/socket.h> constant
Summary: Missing AF_VSOCK <sys/socket.h> constant
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: Sergey Kolosov
URL:
Whiteboard:
Depends On:
Blocks: 1413146
TreeView+ depends on / blocked
 
Reported: 2017-01-27 14:23 UTC by Stefan Hajnoczi
Modified: 2017-08-01 18:09 UTC (History)
10 users (show)

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.
Clone Of:
Environment:
Last Closed: 2017-08-01 18:09:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1291282 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHSA-2017:1916 0 normal SHIPPED_LIVE Moderate: glibc security, bug fix, and enhancement update 2017-08-01 18:05:43 UTC

Internal Links: 1291282

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

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


Note You need to log in before you can comment on or make changes to this bug.