From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105683 invoked by alias); 5 Dec 2016 15:58:37 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 105653 invoked by uid 89); 5 Dec 2016 15:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=getaddrinfo X-HELO: mx1.redhat.com Date: Mon, 05 Dec 2016 15:58:00 -0000 From: Stefan Hajnoczi To: Florian Weimer Cc: libc-alpha@sourceware.org, Jorgen Hansen Subject: Re: [RFC PATCH 0/2] Add AF_VSOCK support to getnameinfo(3) and getaddrinfo(3) Message-ID: <20161205155823.GG30434@stefanha-x1.localdomain> References: <1475144848-4446-1-git-send-email-stefanha@redhat.com> <87mviq96sc.fsf@mid.deneb.enyo.de> <20160930111040.GB16491@stefanha-x1.localdomain> <3649baeb-be14-fa8a-f1af-7ac3637d0547@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2016-12/txt/msg00101.txt.bz2 --Zrag5V6pnZGjLKiw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1988 On Fri, Oct 07, 2016 at 04:02:19PM +0200, Florian Weimer wrote: > On 10/06/2016 01:19 PM, Florian Weimer wrote: >=20 > > > > How do you expect that applications will know that they have to pass > > > > AF_VSOCK to getaddrinfo instead of AF_UNSPEC? > > >=20 > > > 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, UD= P, > > > UNIX, and vsock. > >=20 > > 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. > >=20 > > Do you have a better example? >=20 > I've looked briefly at nfs-utils. I don't see how you can patch in AF_VS= OCK > support using the proposed getaddrinfo support, either. It seems to do t= he > 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=3D3,proto=3Dvsock (Most code paths are not relevant to NFS over AF_VSOCK, which only supports NFSv4+ and therefore no UDP or no rpcbind/portmap.) The port=3DNUM option is passed to mount(2) as a string. See nfs_parse_mount_options() in the kernel for parsing code. 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(). It's not possible to skip getaddrinfo(3) for AF_VSOCK and allocate struct addrinfo manually since the details of the struct addrinfo memory allocation are private to glibc. Stefan --Zrag5V6pnZGjLKiw Content-Type: application/pgp-signature; name="signature.asc" Content-length: 455 -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYRY6fAAoJEJykq7OBq3PIfU4H/ihPlzg8XRvziKYHZS6nqeAy 0+W+wO7fKTadbXjtMN6RwR5luSNqOzB+lmPoVVnTxUbyIm/jfiKOlwjBr+i7cU7l xAZ5OI5SGZmbf+5Kf+0uCc0cntQSqHINaTnDek+9cc8QHy/zSaSOtPbn4hTrkhDs m6QQ75KRgn+K8XTNw9TNmnK1zm8P51aaPqTnl5ODucHXoruwCILOUx7NJmHE6sNe dIJjD30KWillPoCEMCRazrc0y7E8bbLgwRTmoAWuuVwPDqbRH/XsyQ29njQnjLb9 8jQ9uzf7FATxG8dD15n0jc4C6cTmtuCoOgTNCwb6pmOKVIcpb8pBYB/GyUJq68I= =C8P+ -----END PGP SIGNATURE----- --Zrag5V6pnZGjLKiw--