Bug 69241 - When no "port=" is specified on command line, /proc/mounts shows "port=0" on NFSv4 mounts
Summary: When no "port=" is specified on command line, /proc/mounts shows "port=0" on ...
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: NFS (show other bugs)
Hardware: All Linux
: P1 low
Assignee: Chuck Lever
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-22 20:32 UTC by Chuck Lever
Modified: 2022-02-21 16:07 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.13
Tree: Mainline
Regression: No


Attachments
Proposed fix (1.03 KB, patch)
2014-01-22 21:13 UTC, Chuck Lever
Details | Diff

Description Chuck Lever 2014-01-22 20:32:52 UTC
From my /proc/mounts:

---- cut here ----

forain.1015granger.net:/.domainroot/1015granger.net /nfs4/1015granger.net nfs4 rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.51,local_lock=none,addr=192.168.1.63 0 0

bazille.1015granger.net:/share/home /nfs4/1015granger.net/home nfs4 rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.51,local_lock=none,addr=192.168.1.56 0 0

bazille.1015granger.net:/share/home/cel /nfs4/1015granger.net/home/cel nfs4 rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.51,local_lock=none,addr=192.168.1.56 0 0

10.0.0.1:/share/cthon /mnt nfs4 rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=rdma,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.2,local_lock=none,addr=10.0.0.1 0 0

---- cut here ----

All mounts are NFSv4 and done without specifying "port=".  Kernel correctly chooses to use a non-zero port value at mount time, but nfs_show_options() is displaying "port=0".  (This might also cause a remount to fail, but I didn't try that).

When the default port is chosen at mount time, nfs_show_mount_options() should omit displaying "port=".  The relevant logic in nfs_show_mount_options() is:

        if (version == 4) { 
                if (nfss->port != NFS_PORT)
                        seq_printf(m, ",port=%u", nfss->port);
        } else 
                if (nfss->port)
                        seq_printf(m, ",port=%u", nfss->port);
Comment 1 Chuck Lever 2014-01-22 21:13:25 UTC
Created attachment 123071 [details]
Proposed fix
Comment 2 Trond Myklebust 2014-01-22 22:02:36 UTC
Why not just get the relevant info from the RPC layer?
Comment 3 Chuck Lever 2014-01-23 00:38:03 UTC
(In reply to Trond Myklebust from comment #2)
> Why not just get the relevant info from the RPC layer?

Would that work for the remount logic too?
Comment 4 Chuck Lever 2014-01-23 15:46:08 UTC
(In reply to Chuck Lever from comment #3)
> (In reply to Trond Myklebust from comment #2)
> > Why not just get the relevant info from the RPC layer?
> 
> Would that work for the remount logic too?

Expanding a little bit on my question:

The RPC layer stores the port value in rpc_xprt::addr.  To extract the port value, invoke rpc_peeraddr() and then rpc_get_port() on the resulting buffer.

But the port value in the address of a connected transport can never be zero, and we have to be careful to report "port=0" if that's what was used on the command line.

Otherwise, for vers=2/3 mounts, the remount command line could be "port=0" but the RPC layer would return the port value that was discovered via rpcbind query.  The port comparison in nfs_remount() would always fail in that very common case.

Could this work if the port check in nfs_remount() is skipped when the remount command line specified "port=0" ?
Comment 5 Chuck Lever 2014-01-23 15:48:48 UTC
(In reply to Chuck Lever from comment #4)
> Could this work if the port check in nfs_remount() is skipped when the
> remount command line specified "port=0" ?

That may not be the only issue:  I worry about the case where /etc/mtab is symlinked to /proc/mounts.  umount expects to find "port=0" when that's what was specified on the mount command line.
Comment 6 JianhongYin 2017-06-27 07:42:16 UTC
any update ?
Comment 7 Steve Dickson 2018-04-17 17:22:30 UTC
Its been fixed upstream

commit 89a6814d9b665b196aa3a102f96b6dc7e8cb669e
Author: Steve Dickson <steved@redhat.com>
Date:   Thu Jun 29 11:48:26 2017 -0400

    mount: copy the port field into the cloned nfs_server structure.

Note You need to log in before you can comment on or make changes to this bug.