Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH 19/27] NFS: Ensure that NFS version 4 mounts use NFS_PORT if	nfsport wasn't set
Date: Mon, 29 Oct 2007 12:08:21 -0400	[thread overview]
Message-ID: <47260575.2030903@oracle.com> (raw)
In-Reply-To: <EXNANE01S0qPzg9uV5400000825@exnane01.hq.netapp.com>

[-- Attachment #1: Type: text/plain, Size: 3246 bytes --]

Talpey, Thomas wrote:
> But... 2049 is only valid for TCP. Ther eis no such guarantee for RDMA,
> SCTP, etc etc. Wouldn't it be safer/better to fail the mount if no port
> is specified? This is what rpcbind would do if it fails to resolve the port,
> for example.

I'm copying logic already used in the legacy mount ABI.  See "case 1:" 
in the same switch statement.  The behavior there, unless I'm mistaken, 
is that if no port is specified via a mount option, that's the same as 
saying "port=2049".

RFC 3530 states

3.1.  Ports and Transports

    Historically, NFS version 2 and version 3 servers have resided on
    port 2049.  The registered port 2049 [RFC3232] for the NFS protocol
    should be the default configuration.  Using the registered port for
    NFS services means the NFS client will not need to use the RPC
    binding protocols as described in [RFC1833]; this will allow NFS to
    transit firewalls.

The last sentence fragment is pertinent here.  Without the logic I add 
in this patch, text-based NFSv4 mounts won't transit firewalls that 
block the rpcbind protocol, but legacy NFSv4 mounts will work as expected.

I'm not familiar with the v4.1 spec, but I assume (perhaps at my own 
risk) that the firewall transit requirement has not been changed.

In any event, I understand that RDMA uses port 2050, but I thought that 
was just a place holder in the rpcbind protocol; the actual value of the 
port number is never used by the underlying RDMA transport.  In other 
words, is this patch really going to affect RDMA mounts?

> At 01:32 PM 10/26/2007, Chuck Lever wrote:
>> Text-based mount option parsing introduced a minor regression in the
>> behavior of NFS version 4 mounts.  NFS version 4 is not supposed to require
>> a running rpcbind service on the server in order for a mount to succeed.
>>
>> In other words, if the mount options don't specify a port number, the port
>> number is supposed to default to 2049.  For earlier versions of NFS, the
>> default port number was zero in order to cause the RPC client to autobind
>> to the server's NFS service.
>>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>>
>> fs/nfs/super.c |    2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>> index fa517ae..1b2fac8 100644
>> --- a/fs/nfs/super.c
>> +++ b/fs/nfs/super.c
>> @@ -1612,6 +1612,8 @@ static int nfs4_validate_mount_data(void *options,
>> 		if (nfs_parse_mount_options((char *)options, args) == 0)
>> 			return -EINVAL;
>>
>> +		if (args->nfs_server.address.sin_port == 0)
>> +			args->nfs_server.address.sin_port = htons(NFS_PORT);
>> 		if (!nfs_verify_server_address((struct sockaddr *)
>> 						&args->nfs_server.address))
>> 			return -EINVAL;
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> NFS maillist  -  NFS@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfs

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2007-10-29 16:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 17:32 [PATCH 19/27] NFS: Ensure that NFS version 4 mounts use NFS_PORT if nfsport wasn't set Chuck Lever
2007-10-29 14:59 ` Talpey, Thomas
2007-10-29 16:08   ` Chuck Lever [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47260575.2030903@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=Thomas.Talpey@netapp.com \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox