I was trying to figure out why the VOP_UNLOCK() call in null_lookup() was violating a vnode locking assertion, so I tossed a bunch of ASSERT_VOP_LOCKED() calls into null_lookup(). I found something I don't understand ... ASSERT_VOP_LOCKED(dvp, "null_lookup 1"); if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) && (cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME)) return (EROFS); /* * Although it is possible to call null_bypass(), we'll do * a direct call to reduce overhead */ ASSERT_VOP_LOCKED(dvp, "null_lookup 2"); ldvp = NULLVPTOLOWERVP(dvp); ASSERT_VOP_LOCKED(dvp, "null_lookup 3"); vp = lvp = NULL; error = VOP_LOOKUP(ldvp, &lvp, cnp); ASSERT_VOP_LOCKED(dvp, "null_lookup 4"); if (error == EJUSTRETURN && (flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) && (cnp->cn_nameiop == CREATE || cnp->cn_nameiop == RENAME)) error = EROFS; /* * Rely only on the PDIRUNLOCK flag which should be carefully * tracked by underlying filesystem. */ if (cnp->cn_flags & PDIRUNLOCK) VOP_UNLOCK(dvp, LK_THISLAYER, td); The null_lookup {1,2,3} assertions pass, but null_lookup 4 fails. It appears that the VOP_LOOKUP() call to the underlying file system is unlocking the directory vnode in the nullfs file system. How can that happen?Received on Sun Nov 23 2003 - 14:57:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC