On Mon, 20 Oct 2008, Christoph Lameter wrote:
quoted text
> >>> The big issue is dealing with umount.  You could do something like
> >>> grab_super() on sb before getting a ref on the inode/dentry.  But I'm
> >>> not sure this is a good idea.  There must be a simpler way to achieve
> >>> this..
> >> Taking a lock on vfsmount_lock? But that would make dentry reclaim a pain.
> > 
> > No, I mean simpler than having to do this two stage stuff.
> 
> How could it be simpler? First you need to establish a secure
> reference to the object so that it cannot vanish from under us. Then
> all the references can be checked and possibly removed. If we do not
> need a secure reference then the get_dentries() etc method can be
> NULL.

So, isn't it possible to do without get_dentries()?  What's the
fundamental difference between this and regular cache shrinking?

quoted text
> Those inodes are going to be freed by the reclaim code. Why would
> they be busy (unless the case below occurs of course).

Case below was brainfart, please ignore.  But that doesn't really
help: the VFS assumes that you cannot umount while there are busy
dentries/inodes.  Usually it works this way: VFS first gets vfsmount
ref, then gets dentry ref, and releases them in the opposite order.
And umount is not allowed if vfsmount has a non-zero refcount (it's a
bit more complicated, but the essense is the same).

The current SLUB defrag violates this: it gets dentry or inode ref
without getting a ref on the vfsmount or the super block as well.
This means that the umount will succeed (that's OK), but also the
super block will be going away and that's bad.  See
generic_shutdown_super().

quoted text
> > And anyway the dentry could be put back onto the LRU by somebody else
> > between get_dentries() and kick_dentries().  So I don't even see how
> > taking the dentry off the LRU helps _anything_.
> 
> get_dentries() gets a reference. dput will not put the dentry back
> onto the LRU.

Right.

Miklos
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/