On Wed, Jun 04, 2008 at 01:13:08AM +0800, Ian Kent wrote: > "What happens is that during an expire the situation can arise > that a directory is removed and another lookup is done before > the expire issues a completion status to the kernel module. > In this case, since the the lookup gets a new dentry, it doesn't > know that there is an expire in progress and when it posts its > mount request, matches the existing expire request and waits > for its completion. ENOENT is then returned to user space > from lookup (as the dentry passed in is now unhashed) without > having performed the mount request. > > The solution used here is to keep track of dentrys in this > unhashed state and reuse them, if possible, in order to > preserve the flags. Additionally, this infrastructure will > provide the framework for the reintroduction of caching > of mount fails removed earlier in development." > > I wasn't able to do an acceptable re-implementation of the negative > caching we had in 2.4 with this framework, so just ignore the last > sentence in the above description. > Unfortunately no, but I thought that once the dentry became unhashed > (aka ->rmdir() or ->unlink()) it was invisible to the dcache. But, of > course there may be descriptors open on the dentry, which I think is the > problem that's being pointed out. ... or we could have had a pending mount(2) sitting there with a reference to mountpoint-to-be... > Yes, that would be ideal but the reason we arrived here is that, because > we must release the directory mutex before calling back to the daemon > (the heart of the problem, actually having to drop the mutex) to perform > the mount, we can get a deadlock. The cause of the problem was that for > "create" like operations the mutex is held for ->lookup() and > ->revalidate() but for a "path walks" the mutex is only held for > ->lookup(), so if the mutex is held when we're in ->revalidate(), we > could never be sure that we where the code path that acquired it. > > Sorry, this last bit is unclear. > I'll need to work a bit harder on the explanation if you're interested > in checking further. I am. Oh, well... Looks like RTFS time for me for now... Additional parts of braindump would be appreciated - the last time I've seriously looked at autofs4 internal had been ~2005 or so ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
