Subject: kern/20149: switching with held simple lock in amap_unref()
To: None <gnats-bugs@gnats.NetBSD.org, firstname.lastname@example.org>
From: Aymeric Vincent <email@example.com>
Date: 04/03/2004 18:47:29
I'm seeing the same symptoms as described in PR kern/20149 on macppc
and I also believe it's not port-specific.
Namely, amap_unref() acquires a lock on the amap it is working on and
calls amap_pp_adjref() which can happen to indirectly call uvm_anfree()
on some anon formerly contained in the amap.
However, uvm_anfree() can go to sleep() if the anon is BUSY and this
happens sometimes, at least when the system is paging/swapping.
I'm not sure if there is an easy workaround, but it is obviously wrong
that a code path can sleep() when a lock is held. Maybe we should
prepare a list of anon's to free and have them freed in some other
context (by a thread seems overkill?).
Here is the backtrace produced with LOCKDEBUG set:
/* interesting part below */
/* less insteresting from here */