Bug 783147

Summary: Cannot unmount nfsv3 mounts
Product: Red Hat Enterprise Linux 5 Reporter: john.haxby <john.haxby>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact: yanfu,wang <yanwang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.8CC: jch, jiali, jlayton, yanwang
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: nfs-utils-1.0.9-63.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-08 07:34:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 807971    
Attachments:
Description Flags
Proposed patch. none

Description john.haxby@oracle.com 2012-01-19 14:25:03 UTC
Created attachment 556286 [details]
Proposed patch.

Description of problem:

  You cannot unmount an nfs v3 file system.  umount.nfs fails quietly.

Version-Release number of selected component (if applicable): 1.0.9-55.el5


How reproducible: Always


Steps to Reproduce:
1.  Mount an nfs v3 file system with no special options
2.  unmount it with umount or umount -v3
3.
  
Actual results: It stays mounted.


Expected results: It unmounts.


Additional info:

  The problem is in the implemenation of the new resvport (and noresvport)
  option.  The default is to use reserved ports but the code in nfsumount.c
  does not set mnt_server.useresvport and does not look for the [no]resvport
  option.   As a result it takes whatever value mnt_server.useresvport is
  initialised with: as this is on the stack it's undefined but in practice
  it's always zero.   The socket used for unmounting does not then use a
  reserved port and so the unmount fails with an RPC_AUTHERR (which umount
  does not report).

Comment 2 RHEL Program Management 2012-04-02 10:50:46 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 3 yanfu,wang 2012-04-05 03:06:15 UTC
I can't reproduce on nfs-utils-1.0.9-60.el5.

Comment 4 john.haxby@oracle.com 2012-04-05 09:49:31 UTC
You can't reproduce it because the "fix" in 1.0.9-60 is wrong.   The patch I have above puts this code in _nfsumount:

-----------------
	mnt_server.useresvport = TRUE;
        ...
 	if (opts && (p = strstr(opts, "mountvers=")) && isdigit(*(p+10)))
 		pmap->pm_vers = atoi(p+10);
	if (opts && strstr(opts, "noresvport"))
		mnt_server.useresvport = FALSE;
	else if (opts && strstr(opts, "resvport"))
		mnt_server.useresvport = TRUE;
 
 	if (!nfs_gethostbyname(hostname, &mnt_server.saddr))
 		goto out_bad;
----------------

Whereas 1.0.9-60 says this:

----------------
        if (opts && (p = strstr(opts, "mountvers=")) && isdigit(*(p+10)))
                pmap->pm_vers = atoi(p+10);

        mnt_server.useresvport = TRUE;
        if (!nfs_gethostbyname(hostname, &mnt_server.saddr))
                goto out_bad;
----------------

So while this fixes the immediate problem, it has probably broken the new resvport option.   Unfortunately I don't have a server that supports noresvport to test this with.

Comment 5 yanfu,wang 2012-04-05 11:14:33 UTC
hi John,
I still failed to reproduce on 1.0.9-55.el5 as per comment #0, umounted done and not shown by 'mount' and /proc/mounts.
So could you help to point out your steps and environment more detailed again? thanks.

Comment 6 john.haxby@oracle.com 2012-04-05 12:42:20 UTC
I've just built a 1.0.9-55.el5 and I can't reproduce it either.

There is something else going on here, and I'm not sure what.

However, single-stepping in gdb shows mnt_server.useresvport == 0 in _nfsumount() (as per the patch).

However, as I step down through nfs_call_umount() and mnt_openclnt(), mnt_server->useresvport is still zero and get_socket() in mnt_openclnt() is passed zero as its resvp argument.

This results in a call to bind(2) that binds the socket to a non-reserved port and yet the unmount succeeds.

This appears to be wrong, but that is a different bug.  The point is that a reserved port should be the default and it isn't.

The fix that was introduced to set mnt_server.useresvport = TRUE unconditionally is still there.

I can't see the bug that says why that was done and what the rationale was behind it.

It does appear that autofs cannot unmount things.

With 1.0.9-60.el5 do the resvport/noresvport tests still work?   I have no way of testing that.

Not being able to reproduce the problem doesn't mean that the bug is not there :)

Comment 8 Steve Dickson 2012-07-10 17:18:22 UTC
The resvport/noresvport support is not in the RHEL5 kernel. This type of support was not added until the 2.6.28 kernel..

Comment 9 john.haxby@oracle.com 2012-07-10 17:28:08 UTC
That's bizarre.   How come it's in nfs-utils then?

The changelog shows that resvport/noresvport was added in response to a customer request (I can't see the bug, as I recall, but I deduced that).

Comment 10 yanfu,wang 2012-07-11 10:05:02 UTC
Same question and waiting SteveD's reply, see bug https://bugzilla.redhat.com/show_bug.cgi?id=772170#c3

Comment 11 john.haxby@oracle.com 2012-07-11 10:15:19 UTC
I can't read that bug.

Comment 12 yanfu,wang 2012-07-12 03:51:16 UTC
(In reply to comment #11)
> I can't read that bug.

From Steve's reply:
I was saying the RHEL 5 kernel does not support this functionally (which is true), But... What I missed was the RHEL5 mount command does have the functionality... Good Catch!

So Steve, could you re-check this bug? thanks.

Comment 14 yanfu,wang 2012-08-20 11:12:49 UTC
hi John,
I tested on nfs-utils-1.0.9-64.el5 using below mount command, and umount is OK for me.
# mount -t nfs localhost:/tmp -o resvport /mnt
# mount -t nfs localhost:/tmp -o noresvport /mnt

And I do code review, the patch is same with your comment #0.

Could you help to check if the fix satisfy with you now? thanks.

Comment 15 John Haxby 2012-08-31 13:27:47 UTC
Yes, that's great.   Thank you.

Comment 16 yanfu,wang 2012-09-03 10:26:20 UTC
Set to verify according to above comments.

Comment 18 errata-xmlrpc 2013-01-08 07:34:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0068.html