LINUX: Workaround d_splice_alias/d_lookup race

LINUX: Workaround d_splice_alias/d_lookup race

Before Linux kernel commit 4919c5e45a91b5db5a41695fe0357fbdff0d5767,
d_splice_alias in some cases can d_rehash the given dentry without
attaching it to the given inode, right before the dentry is unhashed
again. This means that for a few moments, that negative dentry is
visible to __d_lookup, and thus is visible to path lookup and can be
given to afs_linux_dentry_revalidate.

Currently, afs_linux_dentry_revalidate will say that the dentry is
valid, because d_time and other fields are set; it's just not attached
to an inode. This causes an ENOENT error on lookup, even though the
file is there (and no OpenAFS code said otherwise).

Normally this race is rare, but it can be frequently exercised if
we access the same directory via different names at the same time.
This can happen with multiple mountpoints to the same volume, or by
accessing an @sys directory via its abbreviated and expanded forms.

To get around this, make afs_linux_dentry_revalidate check negative
'dentry's to see if they are unhashed. We also lock the parent inode,
in order to guarantee that a problematic d_splice_alias call isn't
running at the same time (and thus, we know the dentry will not be
unhashed immediately afterwards). This slows down
afs_linux_dentry_revalidate for valid negative 'dentry's a little, but
it allows us to use negative dentry's at all.

Linux kernel commit 4919c5e45a91b5db5a41695fe0357fbdff0d5767 fixes
this issue, which was included in 2.6.34, so don't do this workaround
for 2.6.34 and on.

Change-Id: I8e58ebed4441151832054b1ef3f1aa5af1c4a9b5
Reviewed-on: https://gerrit.openafs.org/12638
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>