On Jan 16, 2014, at 2:45 PM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote: > Date: Thu, 16 Jan 2014 07:07:56 +0000 > From: David Holland <dholland-tech%netbsd.org@localhost> > > On Wed, Jan 15, 2014 at 04:31:07PM +0100, J. Hannken-Illjes wrote: >> I put a diff to http://www.netbsd.org/~hannken/vnode-pass2a-3.diff that >> changes the vnode creation operations to keep the dvp locked. >> >> Any objections or OK to commit? > > I don't understand where all of the zfs changes arise (without wading > into the zfs code) but I'm not going to worry too much about that. > > Whoops, I missed those on my first reading -- in particular, the first > two files, zfs_ioctl.c and zfs_replay.c (the zfs_vnops.c changes look > fine and I'm glad we can now get rid of the comments on insanity I > left there). > > It's not clear to me why the vop protocol change would induce these > zfs changes. I'm particularly nervous because you've made the vops > *stop* unlocking and releasing vnodes, so callers should at most have > to *add* unlocks and vreles, but you've *removed* some vreles and left > things locked. It could be that something causes changes to zfs_zget, > but this seems unlikely. Did you run this code? (I suspect not -- it > looks like the code had broken locking to begin with.) Taylor, you're right. - the change to zfs_ioctl.c was wrong and unneeded (this part is not used from NetBSD). - the change to zfs_replay.c was wrong. Looks like zfs_zget() returns a referenced and unlocked vnode so the attached diff should do it right as soon as VOP_CREATE and VOP_MKDIR get out of "#ifdef TODO". -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)
Attachment:
zfs.diff
Description: Binary data