On Thu, 26 Mar 2009, Ian Kent wrote: > Ian Kent wrote: > > Sage Weil wrote: > >> Would it be possible to avoid the upcall in revalidate, and instead fail > >> and let the subsequent lookup path do it? (I'm guessing the upcall > >> doesn't happen for _every_ revalidate?) > > snip ... > > > > > It was more than three years ago when I tried to make everything go > > through lookup so my memory is pretty unclear now. In the end I think > > there was one case in real_lookup() where the lookup was skipped, > > revalidate was called and failed but lookup wasn't then called again and > > I got an incorrect failure. AFAICR all other code paths that hold the > > mutex over lookup and revalidate perform the revalidate first and then > > the lookup if that fails, which avoids this case. > > I've managed to locate the work that I did on this (on an old machine I > left as it was for posterity). > > I haven't had a chance to look at what I did closely and a lot has > changed in autofs4 since. The one thing that I'm fairly sure I would > need to be able to make this work is the order of the calls in > real_lookup() to be revalidate then lookup. Would that work for > real_lookup() given that we hold the mutex now? Yep, that's what this patch does (though it's easier to see after the 2/2 cleanup patch is applied as well). > In fact this might be an opportunity for me to clean up my sloppy > DCACHE_AUTOFS_PENDING handling by moving it all under the inode mutex. > > Since this is likely to be quite a bit of effort on my part could I > impose on you to help me understand the issue you need to resolve? I'd > really like to feel it's worth the effort. The basic symptom is sporatic ENOENT errors getting returned to userspace when it is clear the file was always there. In my case, it was caused by dentry lease revocation (resulting in a revalidate returning 0) with multiple processes doing path traversal. The root cause is real_lookup() return ENOENT on revalidate failure instead of doing a lookup. sage -- 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
