Re: repeatable ZFS panic: share->excl

From: Attilio Rao <attilio_at_freebsd.org>
Date: Sat, 14 Mar 2009 02:47:54 +0100
2009/3/13, John Baldwin <jhb_at_freebsd.org>:
> John Baldwin wrote:
>
> > Attilio Rao wrote:
> >
> > > 2009/3/13, John Baldwin <john_at_baldwin.cx>:
> > >
> > > > This is similar to the patch I've asked lulf_at_ to test except that it
> is longer and I fix a bug where zfs_lookup() can leak a vnode lock if the
> access check fails. :-)  The last one I sent to lulf_at_ is at
> www.FreeBSD.org/~jhb/patches/zfs_ea.patch.
> > > >
> > >
> > > I really thought zfs_lookup() was returning the lock held as a feature
> assming no LOCKLEAF. Is that a bug instead?
> > >
> >
> > Yes, I think that is the real bug.  Looking at this further I think
> > zfs_get_xattrdir() will return the vnode locked if it has to create a
> > new node via zfs_make_attrdir() but only returns it held and unlocked if
> > it finds an existing one.  So my new patch is to just fix
> > zfs_get_xattrdir() to unlock the vnode if it creates a new one like so:
> >
> > (Sorry, TBird is probably going to butcher all the whitespace):
> >
> > ---
> >
> //depot/user/jhb/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c
> > +++
> >
> /Users/jhb/work/p4/lock/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c
> > _at__at_ -940,6 +940,7 _at__at_
> >         /* NB: we already did dmu_tx_wait() if necessary */
> >         goto top;
> >     }
> > +    VOP_UNLOCK(*xvpp, 0);
> >
> >     return (error);
> >  }
> >
> > A non-butchered version is at
> www.FreeBSD.org/~jhb/patches/zfs_ea.patch.
> >
>
>  So lulf_at_ reports success with this patch.  Pawel, can you review it?

Yeah, I proposed to lulf this same patch yesterday, I just didn't wait
for him to complete the test because I had to sleep, so I think this
is the right fix.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Sat Mar 14 2009 - 00:47:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC