Hi Bruce-
On Apr 9, 2009, at 12:19 PM, J. Bruce Fields wrote:
On Wed, Apr 08, 2009 at 03:32:43PM -0400, Chuck Lever wrote:
On Apr 7, 2009, at 7:14 PM, J. Bruce Fields wrote:
On Tue, Apr 07, 2009 at 03:43:39PM -0400, Tom Talpey wrote:
At 01:11 PM 4/7/2009, Jeff Layton wrote:
On Tue, 07 Apr 2009 12:27:49 -0400
Tom Talpey <tmtalpey@xxxxxxxxx> wrote:
At 12:02 PM 4/7/2009, Chuck Lever wrote:
On Apr 7, 2009, at 11:25 AM, Jeff Layton wrote:
+ /* Use standard NFS port for NFSv4 */
+ if (program == 100003 && version == 4) {
+ port = 2049;
+ goto set_port;
+ }
I think this patch set looks pretty reasonable. Here's my one
remaining quibble.
You can specify "port=" for nfs4 mounts, in which case we want
to use
that value here, too, I think. It would be simpler overall if
the
*Must* use a port= specification. The 2049 definition is only
true for
NFSv4/TCP, as a counterexample the NFSv4/RDMA IANA binding is
port 20049. So slamming the port to 2049 would break NFSv4/RDMA.
rpc.gssd doesn't seem to be rdma-enabled at this point. It only
seems
to handle "tcp" and "udp" in the existing code.
Fair enough. But hardwiring 2049 for all transports is going to
very
problematic. What's the motivation for bypassing the rpcbind query
altogether (that "goto set_port" skips over it)? Why not at least
try the query first?
We're just doing the rpcsec_gss context initiation. Normally that
would
be done over an already-established connection--the only reason we
don't
is because our implementation is split between the client and the
server, so it's more convenient for us to set up a new connection in
rpc.gssd. But we really shouldn't be doing an entirely new rpcbind
call--somebody else already did that for us and is telling us the
results through the rpc_pipefs info file.
This is an entirely separate RPC transport being set up for gssd, and
there seem to be a lot of cases where the kernel (rightfully)
passes a
zero for the port number. In fact, even if the kernel did the
rpcbind
for gssd at some point in the past, gss doesn't have any information
about how old that information is.
So, yes, we do want an rpcbind here.
As long as we don't do it in the NFSv4 case, I'm happy.
As far as I understand it, the kernel won't send up a zero for NFSv4
unless the mount command line says "port=0" which forces an rpcbind
for each transport we use to connect to that server.
For NFSv2/v3, however, not specifying port= on the mount command line
means the kernel will send up zero in most common cases, I think.
Using /etc/services on the client to discover the server's NFSD port
means that if the server has registered the NFS service on some other
port, specifying "port=" will be required on the mount command line
for gssd to work, even though rpcbind on the server is advertising the
correct port already.
My only point is that the above argument is putting the cart before
the
horse a bit: the fact that there's an entirely separate RPC transport
being set up is entirely an artifact of our implementation, and if it
became a problem at some point, then we'd need to consider modifying
the
kernel/gssd interface to eliminate the need for that.
port=0 has a specific well-defined meaning for RPC, which is "do an
rpcbind". If you really think you need to distinguish between "use
this port number," "do an rpcbind," "use the standard port for this
transport," and "consult /etc/services" then I don't think port=0 is
adequate.
Should we even bother to consult /etc/services for NFSv4, since that
port value is required by standard? nfs4mount.c doesn't look at /etc/
services, for example. So today, gssd looks in /etc/services,
nfs4mount.c and the kernel hard-code the port number.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
