Date: Mon, 13 Jun 2011 14:20:54 -0600 From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: fs@FreeBSD.org Subject: Re: Drop of spa_namespace lock in vdev_geom.c Message-ID: <4DF67126.50404@FreeBSD.org> In-Reply-To: <20110613201543.GA1733@garage.freebsd.pl> References: <4DF25544.3020301@FreeBSD.org> <20110613201543.GA1733@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/13/11 2:15 PM, Pawel Jakub Dawidek wrote: > On Fri, Jun 10, 2011 at 11:32:52AM -0600, Justin T. Gibbs wrote: >> Dropping and reacquiring the spa_namespace lock in vdev_geom_open() >> creates a lock order reversal with the spa_config locks. As the >> spa_config locks are not standard mutexes, witness will not warn >> about this issue. I only noticed this problem when debugging a ZFS >> deadlock. The deadlock can be triggered anytime that there are >> multiple insert/remove processes going on (e.g. vdev orphan processing >> while a fault management daemon is onlining a replacement device for >> some other vdev). >> >> I haven't noticed any issues with just holding the namespace lock >> for the duration of the open. Does anyone know why this lock drop >> was added in v28? > I did that as part of @182208 to fix another LOR. Full commit log: > > Change 182208 on 2010/08/10 by pjd@pjd_zoo ... > To make it work I had to fix LOR between the zfsdev_state_lock, the > GEOM topology lock and the spa_namespace_lock. They are now always > obtained in the following order: > 1. zfsdev_state_lock > 2. g_topology_lock > 3. spa_namespace_lock > Also, we can't use taskqueue to scan for VDEVs as this introduces > deadlock (because there is no way to honour the order above). I'll review these code paths later today and see if I can find an alternate way to resolve the issue. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DF67126.50404>