Bug 69241
| Summary: | When no "port=" is specified on command line, /proc/mounts shows "port=0" on NFSv4 mounts | ||
|---|---|---|---|
| Product: | File System | Reporter: | Chuck Lever (chucklever) |
| Component: | NFS | Assignee: | Chuck Lever (chucklever) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | low | CC: | steved, szg00000, trondmy, yin-jianhong |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.13 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | Proposed fix | ||
Created attachment 123071 [details]
Proposed fix
Why not just get the relevant info from the RPC layer? (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? (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" ? (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. any update ? 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. |
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);