This patch has nothing to do with vfsmount references and doesn't hide
anything. It just adds syncronization barrier between do_umount() and
shrink_dcache() since the latter can work with dentries/inodes without
holding locks.
So if you think there is something wrong with it, please, be more specific.
You can only unmount a file system if there are no references to the vfsmount
object anymore. Since shrink_dcache*() is called after checking the refcount of
vfsmount while unmounting the file system, it isn't possible to hold a
reference to a dentry (and therefore call dput()) after this point in
time. Therefore your reference counting on the vfsmount is wrong which is the
root case for your problem of busy inodes.
You didn't take into account shrink_dcache*() on memory pressure. It
works when it works. And when it calls dput() it detaches dentry from
the whole tree and starts to work with inode. do_umount() can
successfully shrink the other part of the tree, since dentry in question
is detached, complain about busy inode (it is really being put on
another CPU, but still busy) and destroy super block.
another scenario from patch comment:
CPU 1 CPU 2
~~~~~ ~~~~~
umount /dev/sda1
generic_shutdown_super shrink_dcache_memory()
shrink_dcache_parent dput dentry
select_parent prune_one_dentry()
<<<< child is dead, locks are released,
but parent is still referenced!!! >>>>
skip dentry->parent,
since it's d_count > 0
message: BUSY inodes after umount...
<<< parent is left on dentry_unused list,
referencing freed super block >>>
Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
