From owner-freebsd-fs@FreeBSD.ORG Sun Oct 14 12:24:29 2012 Return-Path: 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 5E958F43; Sun, 14 Oct 2012 12:24:29 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1D41F8FC0C; Sun, 14 Oct 2012 12:24:29 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 3D92513F; Sun, 14 Oct 2012 14:23:14 +0200 (CEST) Date: Sun, 14 Oct 2012 14:25:04 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: potential zfs/vfs trouble in force umount Message-ID: <20121014122503.GS1383@garage.freebsd.pl> References: <507A8954.3000702@FreeBSD.org> <20121014112546.GH1383@garage.freebsd.pl> <507AAC38.3000709@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D5tFrmRBv7YOLFOK" Content-Disposition: inline In-Reply-To: <507AAC38.3000709@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 12:24:29 -0000 --D5tFrmRBv7YOLFOK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >>=20 > >> 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. > >=20 > > The z_teardown_lock lock is held for reading for every VOP and zfs_umou= nt() > > 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. > >=20 >=20 > What was/is not clear to me is whether zil operations are always called u= nder > 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --D5tFrmRBv7YOLFOK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlB6rx8ACgkQForvXbEpPzSorACg9C7x+wDVuAlLNqTt/DzmS3rF +6IAni4i8L4eD+cEmSuw0X8FA7MIDmnB =52b2 -----END PGP SIGNATURE----- --D5tFrmRBv7YOLFOK--