On Wed, 30 Nov 2005, Trond Myklebust wrote: > On Wed, 2005-11-30 at 23:44 +0800, Ian Kent wrote: > > On Wed, 30 Nov 2005, Trond Myklebust wrote: > > > > > On Tue, 2005-11-29 at 23:15 -0500, Jeff Moyer wrote: > > > > > > > The patch only drops the semaphore if d_lookup finds the dentry and the > > > > dentry has a revalidate routine. I don't follow how you can end up with > > > > multiple dentries for the same file in this case. > > > > > > > > Sorry if I'm missing something obvious. > > > > > > The inode->i_sem is what ensures that nobody can insert a new dentry > > > between the lookup of the cached dentry by d_lookup() and the call to > > > ->lookup() (which instantiates a new dentry). > > > > > > Imagine you have two separate processes that are doing a __lookup_hash() > > > of the same cached dentry. Now imagine that d_revalidate() of the dentry > > > fails. > > > > And that would be why lookup is only called if d_lookup fails in do_lookup > > when called from the link_path_walk routine. Do you think it is possible > > to do this safely in __lookup_hash with a similar re-ordering? > > 2.4 kernels did a second d_lookup() after retaking the i_sem. The > problem is what do you do in the case of a race: you either have to loop > back (may lead to infinite loops of d_lookup()+d_invalidate()) or you do > something like retry once, then return an error (which is what 2.4 > kernels did).
But in this case the semaphore is already held up until the revalidate so I guess the concern is that the dentry goes away after releasing the semaphore? btw, a little aside. I'm having trouble understanding where EEXIST is returned in a call such as sys_mkdir. Can you help? If a call such as sys_mkdir (perhaps in lookup_create) was able to determine the directory exists before taking the semaphore the problem we have here goes away. > > Either choice is unsatisfying which is (I assume) why the current > behaviour was chosen for 2.6 kernels. > > Cheers, > Trond > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
