Similar to the fixes in 226967 and 226987, purge any name cache entries

associated with the previous vnode (if any) associated with the target of
a rename().  Otherwise, a lookup of the target pathname concurrent with a
rename() could re-add a name cache entry after the namei(RENAME) lookup
in kern_renameat() had purged the target pathname.

MFC after:	2 weeks

1 files changed, 7 insertions, 0 deletions

diff --git a/sys/ufs/ufs/ufs_vnops.c b/sys/ufs/ufs/ufs_vnops.c
index ab33ef3..02ee1e0 100644
--- a/sys/ufs/ufs/ufs_vnops.c
+++ b/sys/ufs/ufs/ufs_vnops.c
@@ -1534,8 +1534,15 @@ relock:
 	 * ufs_lookup_ino() and then VFS_VGET(), another thread might do a
 	 * normal lookup of the from name just before the VFS_VGET() call,
 	 * causing the cache entry to be re-instantiated.
+	 *
+	 * The same issue also applies to tvp if it exists as
+	 * otherwise we may have a stale name cache entry for the new
+	 * name that references the old i-node if it has other links
+	 * or open file descriptors.
 	 */
 	cache_purge(fvp);
+	if (tvp)
+		cache_purge(tvp);
 
 unlockout:
 	vput(fdvp);