Bug 663140

Summary: Netfs fails to umount cifs if there are bind mounts active
Product: [Fedora] Fedora Reporter: David Mudrich <dmudrich>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: iarlyy, jlayton, jonathan, kzak, notting, plautrba, rvokal, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: initscripts-9.20.2-1.fc14.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-04 16:38:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch for netfs init script none

Description David Mudrich 2010-12-14 19:52:06 UTC
Created attachment 468687 [details]
Patch for netfs init script

Description of problem:
netfs fails to umount cifs if there are bind mounts active

Version-Release number of selected component (if applicable):
14

How reproducible:
Always for cifs shares

Steps to Reproduce:
1. add e.g. cifs share to /etc/fstab
2. mount -o bind <share> <destination>
3. shutdown
  
Actual results:
cifs vfs no response for cmd 50

Expected results:
Clean unmount and network shutdown

Additional info:
Patch attached.

Comment 1 Bill Nottingham 2010-12-14 20:04:31 UTC
cifs-utils should handle this better; other umount programs do.

Comment 2 Jeff Layton 2010-12-14 21:04:00 UTC
Can you explain what the problem is here and what cifs-utils should do that it's not doing now?

Comment 3 Jeff Layton 2010-12-21 12:52:56 UTC
No response to my question within the last week. Moving this back to initscripts, though maybe it would be better suited as a util-linux bug...

umount.cifs has been deprecated for some time and never shipped as part of cifs-utils. If there's something the kernel needs to do better here, then please reassign this back to me with a proper explanation and I'll have a look.

Comment 4 Bill Nottingham 2011-01-03 16:37:25 UTC
The attached patch simply reverses the order of the filesystems passed on the commandline to 'umount'; if that actually solves the issue, then the umount routines need fixed to not require this for cifs, as other filesystem types don't have this stringent ordering requirement (afaik).

Comment 5 Jeff Layton 2011-01-03 17:56:25 UTC
cc'ing Karel Zak...

No, that's not all that it does. It also circumvents the '-a' logic in /bin/umount. /bin/umount uses the contents of /etc/mtab to determine what to unmount, and I think the problem is likely there.

When I do a cifs mount and then a bind mount of that, I get this in /etc/mtab:

    //server/scratch /mnt/cifs cifs rw 0 0
    /mnt/cifs /mnt/bind none rw,bind 0 0

When I edit /etc/mtab and change that "none" to "cifs" then umount -t cifs -a works as expected.

So, I don't think this is a kernel problem, or a problem with mount.cifs. It's probably a bug in util-linux-ng. /bin/mount should probably fill out the fstype field in /etc/mtab with the proper type when performing a bind mount.

So, reassigning to util-linux-ng for now, unless Karel wants to make a case that it's an initscripts bug.

Comment 6 Karel Zak 2011-01-03 22:10:53 UTC
This is mount(8) bug. Thanks for your bug report.

Comment 7 Karel Zak 2011-01-04 10:32:48 UTC
It's not so simple to fix this problem in mount(8). Sorry. 

The "mount --bind" does not work with a real device, so the filesystem type is unknown and fill in something other than "none" to the /etc/mtab file is difficult.

This problem does not exist on systems without /etc/mtab (e.g. F15).

From my point of view the best way (for now) is to use David's bugfix (from the first comment). It's probably better when initscripts rely on /proc/mounts than on /etc/mtab.

So, reassigning to initscripts.


Note that umount does not work recursively, so it's mistake to umount only subset of mountpoint by any initscipt during system shutdown. There could be a submount, for example

  mount -t cifs //foo  /mnt/foo
  mount -t ext3 /mnt/foo/subdir

then "umount -a -t cifs" will return EBUSY on /mnt/foo. I'll update my upstream TODO list to address all these issues. It seems that at least findmnt(8) should be able to return all submounts for the selected directory.

Comment 8 Bill Nottingham 2011-01-04 16:38:59 UTC
Added on master and F-14 branch, may be in a future F-14 update.

Thanks!

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=328e7a968515028d5668a63e6f4851a9c8c7e4a3

Comment 9 Fedora Update System 2011-02-25 20:40:49 UTC
Package initscripts-9.20.2-1.fc14.1:
* should fix your issue,
* was pushed to the Fedora 14 updates-testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.20.2-1.fc14.1'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/initscripts-9.20.2-1.fc14.1
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2011-02-27 04:52:57 UTC
initscripts-9.20.2-1.fc14.1 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.