Re: [PATCH] Busy inodes after unmount, be more verbose in generic_shutdown_super

[Kirill Korotaev]

> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/