Date: Wed, 10 Mar 2010 19:42:43 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, FreeBSD Stable <freebsd-stable@FreeBSD.org> Subject: Re: Many processes stuck in zfs Message-ID: <4B97DA13.1040900@icyb.net.ua> In-Reply-To: <20100310173143.GD1715@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B97DA13.1040900>