From 1ff80a3400f426648e820a87225361e1366ef95e Mon Sep 17 00:00:00 2001 From: Mateusz Guzik Date: Fri, 7 Aug 2020 19:36:08 +0000 Subject: [PATCH] vfs: release the interlock after failing to set VHOLD_NO_SMR While here add more comments. Diagnosed by: markj Reported by: pho Fixes: r362827 ("vfs: protect vnodes with smr") --- sys/kern/vfs_subr.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 5c25ab86cf9d..fb245cb6e3d2 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -3683,19 +3683,24 @@ vdropl(struct vnode *vp) } if (!VN_IS_DOOMED(vp)) { vdrop_deactivate(vp); + /* + * Also unlocks the interlock. We can't assert on it as we + * released our hold and by now the vnode might have been + * freed. + */ return; } /* - * We may be racing against vhold_smr. + * Set the VHOLD_NO_SMR flag. * - * If they win we can just pretend we never got this far, they will - * vdrop later. + * We may be racing against vhold_smr. If they win we can just pretend + * we never got this far, they will vdrop later. */ if (!atomic_cmpset_int(&vp->v_holdcnt, 0, VHOLD_NO_SMR)) { + VI_UNLOCK(vp); /* - * We lost the aforementioned race. Note that any subsequent - * access is invalid as they might have managed to vdropl on - * their own. + * We lost the aforementioned race. Any subsequent access is + * invalid as they might have managed to vdropl on their own. */ return; }