Drop of spa_namespace lock in vdev_geom.c

[Justin T. Gibbs]

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 at 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