LOOKUP_POSITIVE is not needed anymore.  All callers of path_walk()
treat -ENOENT and negative dentry the same way.  If you want a proof of
correctness - I'll send it, but it's a couple of pages of induction, basically
boiling down to "let's show that for any N we can replace the
               if (lookup_flags & (LOOKUP_POSITIVE|LOOKUP_DIRECTORY))
                       break;
in link_path_walk() with
               if ((lookup_flags & (LOOKUP_POSITIVE|LOOKUP_DIRECTORY)) ||
		   current->link_count <= N)
                       break;
without changing behaviour of the system".  Pretty straightforward for
N = 0, then we look for places that can lead to call link_path_walk()
with current->link_count equal to N and show that if result of the test
changes, behaviour of callers doesn't.  Since the depth of recursion is
limited, we had shown that test in question can be replaced with if (1).
And that's the only place in tree the ever checks for LOOKUP_POSITIVE.

	The real reason behind that is very simple - indeed, suppose
we get a negative dentry out of path_walk().  What the hell could we
do with it?  Its parent isn't locked, so both the name and parent can
change at any moment (could have changed already).  There used to be
places that tried to play "let's get a negative dentry, lock its parent
and start doing something".  All of them racy and all of them fixed
in 2.3.  Fixed by switching to LOOKUP_PARENT...