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.
--
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
