Date: Sun, 14 Oct 2012 13:25:47 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@FreeBSD.org> Subject: Re: potential zfs/vfs trouble in force umount Message-ID: <20121014112546.GH1383@garage.freebsd.pl> In-Reply-To: <507A8954.3000702@FreeBSD.org> References: <507A8954.3000702@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlB6oToACgkQForvXbEpPzTU9wCg1okzChpjWV6PtGUdtO2pBXNO drAAoPSbNK0Kf2OXuR78QeTmmzKAw2NS =ibzW -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121014112546.GH1383>