Sage Weil wrote: > >> There are several cases I need to deal with, apart from path walks >> initiated by the daemon which don't cause any call backs, and so are >> largely handled by trivially returning success. The cases are, an >> expiring dentry that will go away which ->lookup() can't yet handle, an >> expiring dentry that won't go away which ->lookup() should be able to >> handle already, and a straight out mount request which ->lookup() should >> also be able to handle. The tail end of the expire cases can progress >> concurrently with a mount, which is further complicated by the two cases >> of going away or not, so it's all a bit tricky. > > It sounds to me like revalidate should only return success in the trivial, > non-blocking case. And the ->lookup() should be able to handle all > (other) cases. I.e., things should still work correctly (perhaps more > slowly) without any d_revalidate() at all. (It still looks like the main > change needed is for lookup to use d_obtain_alias, instead of returning > NULL unconditionally...) How so? I don't understand how d_obtain_alias() can help in this situation. Can you elaborate please? Ian -- 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
