From fac663fcd7b5cfd1d818a723c6f1901403617528 Mon Sep 17 00:00:00 2001 From: Bob Beck Date: Thu, 10 Dec 2009 16:41:46 +0000 Subject: "fix" from freebsd to hide potential race in silly renames, where a directory gets reclaimed on a forced unmount before the silly file in it gets blown away... fixes an issue seen by phessler@ ok oga@, art@ --- sys/nfs/nfs_vnops.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'sys/nfs') diff --git a/sys/nfs/nfs_vnops.c b/sys/nfs/nfs_vnops.c index df831ceaacc..849f6ef5217 100644 --- a/sys/nfs/nfs_vnops.c +++ b/sys/nfs/nfs_vnops.c @@ -1,4 +1,4 @@ -/* $OpenBSD: nfs_vnops.c,v 1.125 2009/10/19 22:24:18 jsg Exp $ */ +/* $OpenBSD: nfs_vnops.c,v 1.126 2009/12/10 16:41:45 beck Exp $ */ /* $NetBSD: nfs_vnops.c,v 1.62.4.1 1996/07/08 20:26:52 jtc Exp $ */ /* @@ -1465,7 +1465,16 @@ nfs_remove(void *v) int nfs_removeit(struct sillyrename *sp) { - + /* + * Make sure that the directory vnode is still valid. + * XXX we should lock sp->s_dvp here. + * + * NFS can potentially try to nuke a silly *after* the directory + * has already been pushed out on a forced unmount. Since the silly + * is going to go away anyway, this is fine. + */ + if (sp->s_dvp->v_type == VBAD) + return (0); return (nfs_removerpc(sp->s_dvp, sp->s_name, sp->s_namlen, sp->s_cred, NULL)); } -- cgit v1.2.3