On Mon, Apr 6, 2009 at 11:46 AM, 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? Here is what I recall. For v4 we are not supposed to need a portmap/rpcbind call anymore (or at least an "extra" one from gssd). So for cases where we don't get a port number in the upcall, we use the normal port for "nfs". If we get a port number in the upcall, we use it. (That may be the normal port, or a different one. I'm not sure where that value comes from.) I recall there were complaints about the portmap call. That resulted in: http://osdir.com/ml/linux.nfsv4/2005-12/msg00025.html HTH a little? K.C. -- 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
