Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033

[Alan Cox]

The lock-order reversal that precedes this panic makes little sense:

lock order reversal
 1st 0xffffff007fed7c10 PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033
 2nd 0xffffffff8063dce0 UMA pcpu (UMA pcpu) @ /home2/src/sys/vm/uma_core.c:2015

This corresponds to:

void
uma_zfree_arg(uma_zone_t zone, void *item, void *udata)
{
	...
zfree_restart:
	cpu = PCPU_GET(cpuid);
	CPU_LOCK(cpu);				*** 2nd ***
	cache = &zone->uz_cpu[cpu];

zfree_start:
	bucket = cache->uc_freebucket;

	if (bucket) {
		/*
		 * Do we have room in our bucket? It is OK for this uz count
		 * check to be slightly out of sync.
		 */

		if (bucket->ub_cnt < bucket->ub_entries) {
			KASSERT(bucket->ub_bucket[bucket->ub_cnt] == NULL,
			    ("uma_zfree: Freeing to non free bucket index."));
			bucket->ub_bucket[bucket->ub_cnt] = item;
			bucket->ub_cnt++;
#ifdef INVARIANTS
			ZONE_LOCK(zone);	*** 1st ***
			if (keg->uk_flags & UMA_ZONE_MALLOC)
				uma_dbg_free(zone, udata, item);
			else
				uma_dbg_free(zone, NULL, item);
			ZONE_UNLOCK(zone);
#endif
			CPU_UNLOCK(cpu);
			return;

So, whereas Giant isn't held and it should be, the pv zone lock is held
and it shouldn't be.

Even with preemption, it's hard to see how we would wind up in namei()
with the pv zone lock still held.

Alan