tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Vnode API cleanup pass 2a
On Jan 20, 2014, at 5:02 PM, Taylor R Campbell
<campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> Date: Mon, 20 Jan 2014 16:01:07 +0100
> From: J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>
>
> Back to vnode creation operations returning unlocked vnodes I put a new
> diff to http://www.netbsd.org/~hannken/vnode-pass2a-4.diff
>
> Any more objections or OK to commit?
>
> On further consideration, this looks to me like the right approach
> now. I gave it a quick skim, but not a thorough review. It looks
> pretty good, modulo a few little nits below. I assume all the atf
> tests and your other stress tests still pass?
Sure. Now even on a 20-core amd64 with linux/kvm as a host.
> @@ -517,8 +517,10 @@ zfs_replay_create(zfsvfs_t *zfsvfs, lr_c
> error = VOP_MKDIR(ZTOV(dzp), &vp, &cn, &xva.xva_vattr
> /*,vflg*/);
> break;
> case TX_MKXATTR:
> error = zfs_make_xattrdir(dzp, &xva.xva_vattr, &vp, kcred);
> + if (error == 0 && vp != NULL)
> + VOP_UNLOCK(vp);
>
> This looks suspicious -- does zfs_make_xattrdir return a locked vnode?
> I don't immediately see evidence that it does. (Also, if it turns out
> this branch is appropriate, shouldn't ((error == 0) == (vp != NULL))
> be guaranteed?)
Yes, looks like zfs_make_xattrdir returns an unlocked vnode (which means
the current implementation is wrong). Removed this part.
> @@ -1563,10 +1553,11 @@ coda_symlink(void *v)
> saved_cn_flags = cnp->cn_flags;
> cnp->cn_flags &= ~(MODMASK | OPMASK);
> cnp->cn_flags |= LOOKUP;
> error = VOP_LOOKUP(dvp, ap->a_vpp, cnp);
> + if (error == 0)
> + VOP_UNLOCK(*ap->a_vpp);
>
> Can you leave an XXX comment here marking it as a provisional kludge
> until VOP_LOOKUP becomes sane (i.e., returns the vnode unlocked)?
Done.
> @@ -601,8 +601,10 @@ smbfs_create(void *v)
> error = smbfs_smb_lookup(dnp, name, nmlen, &fattr, &scred);
> if (error)
> goto out;
> error = smbfs_nget(VTOVFS(dvp), dvp, name, nmlen, &fattr,
> ap->a_vpp);
> + if (error == 0)
> + VOP_UNLOCK(*ap->a_vpp);
> if (error) goto out;
>
> Can you do the VOP_UNLOCK unconditionally after the `if (error)'
> branch? Generally I find it much easier to read `branch on error'
> than `branch on success' and I try to adhere to that in new code.
> There are a few other cases of this in your patch, although some match
> the surrounding style of doing `if (error == 0)' or would require new
> labels so I wouldn't change those.
Done.
> --- sys/rump/librump/rumpvfs/rumpfs.c 17 Jan 2014 10:55:03 -0000
> 1.122
> +++ sys/rump/librump/rumpvfs/rumpfs.c 20 Jan 2014 09:10:53 -0000
> @@ -564,9 +564,10 @@ makeprivate(enum vtype vt, mode_t mode,
> return rn;
> }
>
> static int
> -makevnode(struct mount *mp, struct rumpfs_node *rn, struct vnode **vpp)
> +makevnode(struct mount *mp, struct rumpfs_node *rn, struct vnode **vpp,
> + bool lock_result)
>
> There are only a couple cases of makevnode(..., true) in your patch,
> in rump_vop_lookup and rumpfs_mountfs. Instead of adding an argument
> to makevnode, why not just call vn_lock after makevnode in those
> cases?
Done. rump_vop_lookup changed as proposed -- this lock will go with the
next pass doing the same for VOP_LOOKUP. rumpfs_mountfs doesn't need a
lock -- an unmount can not happen here:
RCS file: /cvsroot/src/sys/rump/librump/rumpvfs/rumpfs.c,v
@@ -813,4 +812,11 @@ rump_vop_lookup(void *v)
mutex_exit(&reclock);
rv = makevnode(dvp->v_mount, rn, vpp);
+ if (rv == 0) {
+ rv = vn_lock(*vpp, LK_EXCLUSIVE);
+ if (rv != 0) {
+ vrele(*vpp);
+ *vpp = NULL;
+ }
+ }
}
if (dotdot)
@@ -1762,5 +1768,4 @@ rumpfs_mountfs(struct mount *mp)
rfsmp->rfsmp_rvp->v_vflag |= VV_ROOT;
- VOP_UNLOCK(rfsmp->rfsmp_rvp);
mp->mnt_data = rfsmp;
> @@ -183,16 +184,17 @@ ext2fs_mknod(void *v)
> * Remove inode so that it will be reloaded by VFS_VGET and
> * checked to see if it is an alias of an existing entry in
> * the inode cache.
> */
> - VOP_UNLOCK(*vpp);
> (*vpp)->v_type = VNON;
> + VOP_UNLOCK(*vpp);
>
> Can you do this one in a separate tiny commit? It looks like an
> unrelated bug fix.
Done.
--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
(Germany)
Home |
Main Index |
Thread Index |
Old Index