[PATCH] removal of LOOKUP_POSITIVE
authorAlexander Viro <viro@math.psu.edu>
Sat, 2 Mar 2002 05:30:13 +0000 (21:30 -0800)
committerLinus Torvalds <torvalds@penguin.transmeta.com>
Sat, 2 Mar 2002 05:30:13 +0000 (21:30 -0800)
commit2dee55cd6c8eb5362b5c10616dc866f0342425ad
treea6a2c1f2cfce753b57091863d1848f1262c87805
parente145fcfa47b9073e1786a4d88e419463653fc7d5
[PATCH] removal of LOOKUP_POSITIVE

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...
fs/exec.c
fs/intermezzo/presto.c
fs/intermezzo/vfs.c
fs/namei.c
fs/namespace.c
fs/nfsd/export.c
fs/open.c
fs/super.c
include/linux/fs.h
net/unix/af_unix.c