| Summary: | umount race condition | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Albert Strasheim <fullung> | ||||
| Component: | util-linux | Assignee: | Karel Zak <kzak> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | esandeen, fullung, gansalmon, itamar, jonathan, kernel-maint, kzak, lczerner, madhu.chinakonda | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-08-09 12:40:30 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
The problem happens here at fs/namespace.c in umount syscall:
retval = -EINVAL;
if (path.dentry != path.mnt->mnt_root)
goto dput_and_out;
I'll look more closely at why this is happening.
-Lukas
Please don't copy kernel maintainers - we already get copies of all bugzilla mail. Btw, this fails on upstream kernel as well. Also it fails only if you are trying to umount it using the device, not mount point. This works without any problems (for me): 1. boot with loop.max_loop=256 2. sudo ./testext4.py 3. cat /proc/mounts | grep /dev/loop | cut -d " " -f 2 | perl -ne 's/^/sudo umount /; s/$/&/; print' | sh -x -Lukas I think that this is not ext4-specific either, correct? thanks, -Eric Yes, I reproduced the same behavior with XFS. (In reply to comment #4) > I think that this is not ext4-specific either, correct? > Oh, I am sorry I have not made it clear, no it is not ext4 specific. -Lukas That's fine, I thought so, just wanted to be sure. Thanks! -Eric Any news on this one? Karel Zak should have better insight into the problem. Assigning to him. Few notes:
- in Fedora 15 is mtab symlink to /proc/mounts (!)
- umount(8) should be called with directory name rather than device name (see umount(8) man page), umount by device name is bad idea for many reasons...
- it was never supported to umount by loopdev name on systems with regular mtab
(note that we're talking about loopdevs created by mount -o loop)
In the regular mtab is the backing file instead of the device name. The translation from the device to the backing file is possible on kernel >= 2.6.37 where kernel exports the loopdev information in sysfs.
This is reason why this feature is not implemented yet. (Anyway this feature is *unnecessary* on systems where mtab is symlink to /proc/mounts.)
I'll add this as a feature request to the util-linux upstream TODO file.
You have to update your scripts to use directory names, for example:
for x in $(findmnt -r -o MAJ:MIN,TARGET | awk '/7:/ { print $2 }'); do
sudo umount $x;
done
Closing...
|
Created attachment 497978 [details] mount script Description of problem: Doing multiple umounts in parallel of a bunch of ext4 file systems causes umount to return "not mounted" for some file systems, even if /etc/mtab is a symlink to /proc/mounts. Version-Release number of selected component (if applicable): kernel-2.6.38.4-20.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. boot with loop.max_loop=256 2. sudo ./testext4.py 3. cat /proc/mounts | grep /dev/loop | cut -d " " -f 1 | perl -ne 's/^/sudo umount /; s/$/&/; print' | sh -x Actual results: A few of the umounts fail with "not mounted". If you check /proc/mounts, the file systems are in fact mounted and another attempt to umount them succeeds. I am running on a machine with 24 cores.