On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote: > Ewwww... NAK in that form. Just what will happen if the last component > given to that sucker will be . or .., for starters? Or a symlink, with > '/' added to it to force following the damn thing? OK, in more details: * we are changing a user-visible ABI here - kern_path() with LOOKUP_FOLLOW had been there since the introduction of that misc device (OK, it used to be path_lookup(), but that changes nothing). IOW, we used to follow symlinks there, now we do not. * pathname may end on more than one slash. Modified that way, the code won't do anything good (not to mention that d_lookup() on an empty string is an interesting torture test for fs/dcache.c; probably you'll just find nothing, but normally the function is never called with such arguments, so...). In any case it's an ABI change. * pathname may end with something/. or something/..; again, d_lookup() won't find you anything now, so we have an ABI change. That aside, I'm really not happy with this kind of games; this stuff clearly belongs in fs/namei.c where we can simply see the last component. Doing that on the level of "let's scan the pathname for slashes, etc." is just plain wrong. Let's step back for a minute here; what are you trying to do? You have a pathname that should resolve to a mountpoint, without triggering automount (or crossing into the mountpoint, for that matter) and you want struct path for the bottom of that mount stack? Or is it something completely different? -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
