Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > We may indeed have to revert for sanity at this point, but I have to > say that I think the arguments have been very weak, and the logic for > when to auto-mount and when not to seems to not really be based on any > real logic. Can you look over the patchset I've just posted. It moves the policy on whether or not to suppress automount out of follow_automount() - which is probably the wrong place for it anyway. Depending on which patch you want to stop at it can reinstate the pre-Miklos behaviour; reinstate the Miklos behaviour, but without the regression; or reinstate the pre-d_automount behaviour. > For example, I think the whole "let's consider lstat different from > stat" model is broken. It works for symlinks, but that's because That's a reasonable way to look at it; the difference between stat and lstat is about handling symlinks only. Furthermore, we have fstatat, so this isn't really an issue - that can be given flags to let userspace decide what it should do. getxattr and co. are trickier because they don't have an AT_ flags form, and it can be argued that these, lgetxattr and co. included should automount. However, that would seriously upset ls, so I think we have to leave lgetxattr not automounting, and so getxattr should follow. We should consider adding an AT_ flags form of the xattr calls, but that's another matter we can argue over later. > So *that* is why I thought the LOOKUP_DIRECTORY flag was so nice. And > I still suspect that if paired with LOOKUP_OPEN, it would actually be > a complete solution that avoids the crazy issues with "random > implementation detail" and could give us something that is both > accessible from user space *and* something we can explain to a user > from a logical basis. I don't like this because it's fragile. We're giving an implied second meaning to LOOKUP_DIRECTORY/LOOKUP_OPEN, albeit a reasonable one. Can we please move the policy to the pathwalk callers instead? David -- 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
