Sorry for the long delay on this. 2011/8/31 Jeff Layton <jlayton@xxxxxxxxxx>: > If the parent dentry is negative, you mean. Ok, Good point... > > Ok, so you're proposing to wrap this check in a big mutex to prevent > this race when the parent dentry is negative. In the event that it's > positive though, you'll need to make sure that you take the parent's > i_mutex. Yes, that's what I meant. > > I don't have a great feel for this sort of dcache trickery, but this > whole scheme sounds like it's going to break a lot of assumptions about > how the dcache works. In particular having negative dentries with > children sounds very problematic. > > Would it be better to simply make the initial dentry in this case be a > disconnected or root dentry (see DCACHE_DISCONNECTED), and then later > "graft" it into a larger tree if the parent comes to life? > I am not sure that I understand you right. As I see what you suggest: Let's predict we have mounted //server/share/a/ so 1. Dummy superblock root is set to //server/share/a/. 2. Get an inode and a dentry for //server/share/a/. Then, we mount //server/share/, so 3. Get an inode and a dentry for //server/share/ Then, we reach //server/share/a from the second share, so we need to find the existing dentry from the first share. We can store all dentries that pass through cifs_lookup and cifs_get_root with a full path hash and use them in future when such a path is requested. Makes sense? -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
