Date: Wed, 10 Mar 2010 19:04:01 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-fs@FreeBSD.org, FreeBSD Stable <freebsd-stable@FreeBSD.org> Subject: Re: Many processes stuck in zfs Message-ID: <20100310180401.GG1715@garage.freebsd.pl> In-Reply-To: <4B97DA13.1040900@icyb.net.ua> References: <864468D4-DCE9-493B-9280-00E5FAB2A05C@lassitu.de> <20100309122954.GE3155@garage.freebsd.pl> <EC9BC6B4-8D0E-4FE3-852F-0E3A24569D33@sarenet.es> <20100309125815.GF3155@garage.freebsd.pl> <CB854F58-03AF-46DD-8153-85FA96037C21@sarenet.es> <BFF1E2D6-B48A-4A5E-ACEE-8577FDB07820@sarenet.es> <20100310110202.GA1715@garage.freebsd.pl> <E04F91AA-B2C4-4166-A24A-74F1BEF01519@sarenet.es> <20100310173143.GD1715@garage.freebsd.pl> <4B97DA13.1040900@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Wed, Mar 10, 2010 at 07:42:43PM +0200, Andriy Gapon wrote: > on 10/03/2010 19:31 Pawel Jakub Dawidek said the following: > > This should be impossible. If we are that deep in zfsvfs_teardown(), it means > > that we hold the z_teardown_lock exclusively. And we do as 'show alllocks' > > output confirms. But if we are holding this lock exclusively we shouldn't be > > that deep in create code path, because we need hold this lock as reader. > > It isn't visible in 'show alllocks' output, because this lock is special > > (rrwlock.c). > > BTW, it seems that our 'stock' rwlock implements exactly the same thing as > rrwlock.c - recursive readers, etc. But you cannot sleep while holding our rwlock(9). -- Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuX3xAACgkQForvXbEpPzTK3wCghF57qjGHuo2cJWJ8ySWpSNr3 bXQAnj0etk/l9wDe7BFzglE0vs3igsOw =pLu5 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100310180401.GG1715>