From: Paul Menage <pmenage@ensim.com>
To: Maneesh Soni <maneesh@in.ibm.com>
cc: pmenage@ensim.com, linux-kernel@vger.kernel.org, viro@math.psu.edu
Subject: Re: [RFC] link_path_walk cleanup
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 26 Apr 2002 14:28:26 -0700
Message-Id: <E171DGU-0003m7-00@pmenage-dt.ensim.com>
Sender: linux-kernel-owner@vger.kernel.org


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/