On Mon, 6 Apr 2009 11:46:33 -0400 Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > On Apr 6, 2009, at 11:21 AM, Jeff Layton wrote: > > On Mon, 6 Apr 2009 11:03:11 -0400 > > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > >> On Apr 3, 2009, at 3:04 PM, Jeff Layton wrote: > >>> On Wed, 1 Apr 2009 14:01:30 -0400 > >>> Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >>> > >>>> As far as I understand it, the ai_socktype and ai_protocol fields > >>>> are > >>>> used to return the values needed for subsequent socket(2)/bind(2) > >>>> system calls. In this case you are not using these fields from the > >>>> results... > >>>> > >>>> If ai_protocol is zero, then getaddrinfo(3) assumes you want one > >>>> copy > >>>> of the address for each supported protocol type, so it returns > >>>> three > >>>> structures (one for IPPROTO_UDP, one for IPPROTO_TCP, and one > >>>> with a > >>>> zero protocol number). The contents, except for the socktype and > >>>> protocol fields, are the same for each. > >>> > >>> Hypothetical situation... > >>> > >>> Suppose there is a service in /etc/services that has a different > >>> port > >>> number for tcp than for udp: > >>> > >>> fooserv 50001/tcp > >>> fooserv 50002/udp > >>> > >>> You're saying that getaddrinfo will return the same port number in > >>> all > >>> of the returned structures? Won't that mean that one of the port > >>> numbers > >>> is wrong? That seems broken if so... > >> > >> I was trying to describe observed behavior here -- it's pretty > >> unlikely that there will be different port numbers in these returned > >> structures. It's difficult to say precisely how this is supposed to > >> behave based on the man page or even browsing the glibc source code > >> for a few minutes. > >> > >> It's certainly possible to set up /etc/services as you suggest, but > >> there is an IANA policy to assign the same port for both transports. > >> As near as I can tell the reason we have the transport listed in / > >> etc/ > >> services at all is because some protocols support only one transport. > >> So IMO it would be quite unlikely to encounter such a case where the > >> port number depended on the transport. > >> > >>> If that's not the case, then I think we need to at least set the > >>> ai_protocol in the hints. > >> > >> Perhaps that's true. What are the expected values of @service ? > > > > I've only ever seen "nfs" here, but I guess you could use this with > > others. Maybe "nfsacl" too? > > What's even stranger is that one is supposed to use rpcbind to figure > out what NFS port to use, not /etc/services. > > > IANA might not set different port like this, but there's nothing > > that stops someone from doing this at their site. > > True, but one might expect that setting the NFS service port via > rpc.nfsd on the server would make gssd use that port too. I guess > that's why the port number is now passed up from the kernel. > > > I agree that it's an unlikely (and somewhat pathological) situation, > > but it's easy to deal with -- just set the protocol in the hints. I've > > confirmed that it makes getaddrinfo do the right thing. > > That's good. I think we need to understand exactly what this is > supposed to do, though. Should we use an rpcbind call here instead? > This is _rpc_ gssd, after all. If it's OK as it stands, then I think > some comments about why this works this way are in order :-) > > Kevin, can you enlighten us? > That's a very good point. It does seem like this should be something we resolve with rpcbind instead of locally. This sure would be simpler if we could just depend on having the port in the upcall, but I guess that would break backward compatibility. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
