Re: diagnostic assertion "anon->an_lock == amap->am_lock"

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Sat, Jun 25, 2011 at 3:28 PM, dieter roelants
<dieter.NetBSD%pandora.be@localhost> wrote:
> On Fri, 24 Jun 2011 01:48:56 +0000 (UTC)
> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
>
>> hi,
>>
>> > I'm now running a more recent kernel (from yesterday morning). This
>> > time it hit `"pmap == curpmap" failed: file
>> > "/build/src/sys/arch/x86/x86/pmap.c", line 757`
>>
>> this might be fixed by pmap.c rev.1.126.
>
> It could very well be, but the assertion in the subject is still
> triggered. Hmm, no, it's not the one in the subject. This time it is.
> "an->an_lock == amap->am_lock" failed: file src/sys/uvm/uvm_amap.c,
> line 1459.

IIUC, this is caused by incorrect reference counting of one of
amaps/anons and/or their locks.  I guess we need to apply the
mutex_obj_* changes yamt@ did for an_lock, to am_lock too?

>
> traces are:
>
> cpu0:
> uvm_fault...
>
> cpu1:
> pmap_remove_pv()
> pmap_remove_pte()
> pamp_remove()
> uvm_unmap_remove()
> uvm_unmap()
> uvmsapce_exec()
> execve1()
> syscall()
>
> cpu2:
> lockdebug_wantlock()
> cache_lookup()
> ufs_lookup()
> VOP_lookup()
> lookup_once()
> namei_tryemulroot()
> namei()
> vn_open()
> sys_open()
> syscall()
>
> cpu3:
> breakpoint()
> panic()
> kern_asert()
> amap_lookups()
> uvm_fault_internal()
> trap()
>
> kind regards
> dieter
>
>>
>> YAMAMOTO Takashi
>