Bug 31432

Summary: umount(8) and unmount(2) don't corespond by semantic
Product: Base System Reporter: vova <vova>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description vova 2001-10-22 15:40:00 UTC
 umount(8) first tries to lookup a mountpoint in result list returned by
 getfsstat() then, if found, calls unmount(2).
 If any directory component above mountpoint was renamed, it is not possible
 to unmount this mountpoint because lookup fails.

So unmount(2) needs real directory corresponding to the mountpoint to be
unmounted, but umount(8) tries to compare it with list of paths saved by
mount(2) and fails in case of rename.

Fix: 

Remove getfsstat() lookup in umount(8).
How-To-Repeat: 
# mount -t linprocfs none /tmp/x/y
# mv /tmp/x /tmp/z
# umount /tmp/z/y
umount: /tmp/z/y not found in mount table, unmounted it anyway
# umount /tmp/x/y
umount: unmount of /usr/tmp/x/y failed: No such file or directory
# cat > um.c
main(int ac, char **av) {
unmount(av[1], 0);
}
^D
# gcc um.c
# ./a.out /tmp/z/y
# mount | grep linproc
#
Comment 1 mb 2001-10-22 16:41:37 UTC
This is not a bug.

You can unmount a mounted filesytem by:

1. the mounted directory
2. the mounted name.

It is clear that  if you rename a mountpoint, that you can't unmount it
by the name
itself.

The checks umount(8) does, are rather complex. umount(8) does a check,
if
the mounted name matches the original mountpoint. We need this to handle

overlay mounts properly. Your suggestion does break overlay mounts
unmounting
order !

If it is not possible to unmount like in your example, you have to
unmount the
mounted name:

umount linprocfs

That's it.

Martin


-- Martin Blapp, mb@imp.ch
------------------------------------------------------------------
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA  DF2C 19C6 DCD1 1B3A EC9C
------------------------------------------------------------------
Comment 2 Craig Rodrigues freebsd_committer freebsd_triage 2006-05-15 07:35:29 UTC
State Changed
From-To: open->closed

Not a bug, as described by Martin Blapp.