Description of problem: A NFS export mounted using version 4 and TCP shows up as UDP in /proc/mounts Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: [root@dhcp37-72 tmp]# uname -r 2.6.9-22.EL [root@dhcp37-72 tmp]# mount -t nfs4 -o proto=tcp dhcp37-74:/ rhel-4/ [root@dhcp37-72 tmp]# mount -t nfs4 dhcp37-74:/ on /tmp/rhel-4 type nfs4 (rw,proto=tcp,addr=172.16.37.74) [root@dhcp37-72 tmp]# grep nfs4 /proc/mounts dhcp37-74:/ /tmp/rhel-4 nfs4 rw,v4,rsize=32768,wsize=32768,hard,intr,udp,nolock,addr=dhcp37-74 0 0 [root@dhcp37-72 tmp]# netstat -tn Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 172.16.37.72:800 172.16.37.74:2049 ESTABLISHED Actual results: /proc/mounts shows that UDP is used Expected results: /proc/mounts should show TCP Additional info:
Created attachment 120611 [details] Proposed patch
Actually, it looks like upstream fixed this with a kernel patch. We have most of the patch in RHEL4 already, but are missing the delta that removes ",udp" from the output. Too late for 4.6, we'll try for 4.7.
Created attachment 159643 [details] upstream kernel patch -- show correct options for nfsv4 This is the patch that went upstream. We already have all but the first delta that removes this line: { NFS_MOUNT_TCP, ",tcp", ",udp" }, The question is, will removing this break anything in userspace? I tend to think not, but maybe it's better to just fix it so that these strings are still present, but correct...
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 159776 [details] patch -- remove redundant protocol option from /proc/mounts This pulls in the missing delta from the earlier patch. This would bring us into line with upstream, but I suppose there's a chance that this could break applications that are looking for 'tcp' or 'udp' alone as an option. I'll propose this first, but if it's deemed to risky I'll fall back and change it to keep the old option (but fix it).
Looks like umount actually looks for a 'tcp' or 'udp' mount opt. Before I can propose this I'll need to check that hasmntopt(...,"udp") will still match for "proto=udp".
Created attachment 197391 [details] updated patch -- add the option back, but correct it This patch is similar to the last one, but also adds an extra ,tcp or ,udp option in addition to the proto= option. At this late date, I'd hate to break anything in userspace that's depending on seeing this option in /proc/mounts and correcting it is fairly trivial.
QE ack for RHEL 4.7
Committed in 68.8
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0665.html