On Sun, 08 Nov 2009 19:30:55 -0800 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote: > Jeff Layton <jlayton@xxxxxxxxxx> writes: > > >> Hmm. Looking at the code I get the impression that a file bind mount > >> will have exactly the same problem. > >> > >> Can you confirm. > >> > >> If file bind mounts also have this problem a bugfix to to just > >> proc seems questionable. > >> > > > > I'm not sure I understand what you mean by "file bind mount". Is that > > something like mounting with "-o loop" ? > > # cd /tmp > # echo foo > foo > # echo bar > bar > # mount --bind foo bar > # cat bar > foo > # > > > I'm not at all opposed to fixing this in a more broad fashion, but as > > best I can tell, the only place that LAST_BIND is used is in procfs. > > proc does appear to be the only user of LAST_BIND. With a file bind > mount we can get to the same ok: label without a revalidate. The > difference is that we came from __follow_mount instead of follow_link. > > At least that is how I read the code. > Thanks. Yes, you're correct. That scenario does seem to have a similar problem. I'm not quite sure yet how to fix it there yet. It's easy enough to force a d_revalidate at a higher level. The tricky bit is what to do when that returns 0 or an error. When I spoke to Al about this, he suggested returning -ESTALE from the follow_link routine if that occurs. That would force LOOKUP_REVAL to get set and cause the whole chain of dentries to be revalidated back up to the root (if necessary). That's a little more difficult in the file bind mount case as I don't see where it calls link_path_walk at all and hence can't really deal with an ESTALE on a reval properly. I'll need to study this code some more to see what the right fix is. If you (or anyone) has a suggestion, I'd love to hear it. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
