potential zfs/vfs trouble in force umount

[Pawel Jakub Dawidek]

On Sun, Oct 14, 2012 at 03:12:40PM +0300, Andriy Gapon wrote:
> on 14/10/2012 14:25 Pawel Jakub Dawidek said the following:
> > On Sun, Oct 14, 2012 at 12:43:48PM +0300, Andriy Gapon wrote:
> >> 
> >> I think that there is the following potentially troublesome scenario. One
> >> thread does zil_commit and obtains a znode pointer using zfs_zget.  At
> >> this point the thread doesn't have any locks on either the znode or its
> >> vnode.  the only thing that is supposed to keep them around is a
> >> reference on the vnode. If a force umount is going on in parallel, the
> >> one of the first things it does is calling vflush(FORCECLOSE) (this
> >> happens before closing down zil).  vflush force-reclaims all vnodes in
> >> this case (even when v_usecount > 0).  So the znode in question gets
> >> destroyed. Later, when the first thread tries to dereference the znode
> >> pointer it would crash.
> > 
> > The z_teardown_lock lock is held for reading for every VOP and zfs_umount()
> > obtains this lock for writing before calling vflush(FORCECLOSE) and sets
> > z_unmounted to true. This in turn will make every new VOP to return with
> > EIO. This ensures that no VOP is in-progress when vflush() is called.
> > 
> 
> What was/is not clear to me is whether zil operations are always called under
> z_teardown_lock (aka ZFS_ENTER)...

All VOP start from acquiring this lock. If there is a zil_commit() you
are talking about which is not part of a VOP, then it should be
investigated separately.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20121014/d6a55612/attachment.sig>