Date: Tue, 27 Jul 2004 22:53:40 -0500 From: Alan Cox <alc@cs.rice.edu> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033 Message-ID: <20040728035340.GA18577@cs.rice.edu> In-Reply-To: <Pine.NEB.3.96L.1040727184919.3788J-100000@fledge.watson.org> References: <022801c47429$b8957420$471b3dd4@digiware.nl> <Pine.NEB.3.96L.1040727184919.3788J-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040728035340.GA18577>