Messages in this thread | | | From | Paul Menage <> | Subject | Re: [RFC] link_path_walk cleanup | Date | Fri, 26 Apr 2002 14:28:26 -0700 |
| |
Hi Maneesh,
The handling of '/' in path_walk() and vfs_follow_link() is broken - if the pathname consists entirely of '/' characters, then lookup_parent returns the base immediately without setting nd->last. If there's more than one '/', then the check for looking up '/' won't be triggered, and walk_one() will be called with an undefined nd->last.
So e.g. running
ls '//'
produces
ls: //: File name too long
(but I suspect that it could Oops, depending on what was on the stack when the nameidata was allocated.)
Ideally the tests in vfs_follow_link() and path_walk() ought to be testing for (nd->last_type == LAST_ROOT), rather than checking explicitly for '/' followed by NUL. But that doesn't work, as last_type is only set if you include LOOKUP_PARENT in the flags. Setting last_type on every path element resolution would probably be unecessary overhead given the relative infrequency of looking up "/".
So the alternative that I suggest is to change lookup_parent() as follows:
while (*name=='/') name++; if (!*name) { nd->last = (struct qstr) { name : ".", len : 1, hash : 0 }; goto return_base; }
and remove the tests for "/" in vfs_follow_link() and path_walk(). Setting nd->last to refer to "." will cause walk_one() to return immediately, so the zero hash value is OK.
Paul
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |