From owner-freebsd-fs@FreeBSD.ORG  Sun Oct 14 09:43:53 2012
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id 54479744;
 Sun, 14 Oct 2012 09:43:53 +0000 (UTC) (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
 by mx1.freebsd.org (Postfix) with ESMTP id 6F18F8FC0A;
 Sun, 14 Oct 2012 09:43:51 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
 [212.40.38.100])
 by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28635;
 Sun, 14 Oct 2012 12:43:50 +0300 (EEST)
 (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
 by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
 id 1TNKjd-000Cat-Sj; Sun, 14 Oct 2012 12:43:50 +0300
Message-ID: <507A8954.3000702@FreeBSD.org>
Date: Sun, 14 Oct 2012 12:43:48 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:16.0) Gecko/20121013 Thunderbird/16.0.1
MIME-Version: 1.0
To: "freebsd-fs@freebsd.org" <freebsd-fs@FreeBSD.org>
Subject: potential zfs/vfs trouble in force umount
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset=X-VIET-VPS
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Oct 2012 09:43:53 -0000


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.

-- 
Andriy Gapon