Re: [RFC PATCH 0/2] Add AF_VSOCK support to getnameinfo(3) and getaddrinfo(3)

[Stefan Hajnoczi <stefanha at redhat dot com>]

On Mon, Dec 05, 2016 at 05:02:35PM +0100, Florian Weimer wrote:
> On 12/05/2016 04:58 PM, Stefan Hajnoczi wrote:
> > On Fri, Oct 07, 2016 at 04:02:19PM +0200, Florian Weimer wrote:
> > > On 10/06/2016 01:19 PM, Florian Weimer wrote:
> > > 
> > > > > > How do you expect that applications will know that they have to pass
> > > > > > AF_VSOCK to getaddrinfo instead of AF_UNSPEC?
> > > > > 
> > > > > For example ncat(1) has --unixsock and --udp command-line options.  A
> > > > > --vsock option can be added.  At that point the program knows to use
> > > > > AF_VSOCK and the same getaddrinfo(3) code path can be used by TCP, UDP,
> > > > > UNIX, and vsock.
> > > > 
> > > > ncat doesn't use getaddrinfo AFAICS, so this isn't going to help it. The
> > > > larger nmap codebase has a call to getaddrinfo, but the code leading to
> > > > it assumes 16-bit port numbers, so it won't be able to use getaddrinfo
> > > > either.
> > > > 
> > > > Do you have a better example?
> > > 
> > > I've looked briefly at nfs-utils.  I don't see how you can patch in AF_VSOCK
> > > support using the proposed getaddrinfo support, either.  It seems to do the
> > > address and service lookup separately.
> > 
> > There are quite a few code paths in mount.nfs(8), maybe you are looking
> > at an unrelated one?  The nfs-utils patch series I've proposed does not
> > use service lookup:
> > 
> > https://www.spinics.net/lists/linux-nfs/msg60291.html
> > 
> >   # mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> 
> Well, that was my point.
> 
> You claimed that we need to add this to getaddrinfo to simplify porting
> sockets code to AF_VSOCK.  But based on my analysis of the examples you
> provided, using getaddrinfo would not simplify matters at all or introduce
> bugs (due to truncation of port numbers to 16 bits).

getaddrinfo(3) is used by mount.nfs(8) to go from string to sockaddr
(service lookup isn't used though).  Due to the freeaddrinfo(3) issue I
explained below it's much simpler to have getaddrinfo(3) support than to
modify the program to treat struct addrinfo specially for AF_VSOCK only.

You disagree that getaddrinfo(3) support simplifies here?

> > One of the factors that makes me think glibc should support AF_VSOCK in
> > getaddrinfo(3) is that programs that pass around struct addrinfo are
> > hard to modify.  Only glibc can allocate struct addrinfo because only
> > glibc knows how to free addrinfo in freeaddrinfo().
> 
> That's certainly valid.  But then, I don't see any programs which use
> getaddrinfo and could transparently upgrade to AF_VSOCK anyway.

Stefan

Attachment: signature.asc
Description: PGP signature