NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/38415: sysctl panic: locking against myself


I did some inspection on the dump(s) I got lying around her due to the bug.
The analysis reveals:

This box crashes repeatedly with the "locking against myself" panic.
The backtrace is always the same:

(gdb) where
#0  cpu_reboot (howto=256, bootstr=0x0)
    at /src/src/sys/arch/i386/i386/machdep.c:884
#1  0xc05796f8 in panic (fmt=0xc0a07860 "LOCKDEBUG")
    at /src/src/sys/kern/subr_prf.c:260
#2 0xc0572f46 in lockdebug_abort1 (ld=0xc0d2cb60, lk=0xc0d35a40, func=0xc0a0757f "lockdebug_wantlock", msg=0xc0a075c0 "locking against myself", dopanic=true)
    at /src/src/sys/kern/subr_lockdebug.c:794
#3 0xc05725b1 in lockdebug_wantlock (lock=0xc0d0dae4, where=3226301243, shared=0) at /src/src/sys/kern/subr_lockdebug.c:509
#4  0xc054f980 in rw_vector_enter (rw=0xc0d0dae4, op=RW_WRITER)
    at /src/src/sys/kern/kern_rwlock.c:266
#5  0xc04d733b in vm_map_lock (map=0xc0d0dae0)
    at /src/src/sys/uvm/uvm_map.c:531

Tries to lock a map for which it already has map->lock.

#6  0xc04dd6f2 in uvm_kmapent_free (entry=0xcf28c06c)
    at /src/src/sys/uvm/uvm_map.c:4597

The entry to be freed is the last on in some ukh (ukh->ukh_nused == 1).
There are mote ukh's available (ukh->ukh_listq.le_next != NULL)
Tries to lock the map of the ukh (i.e. kernel_map).

#7  0xc04d796f in uvm_mapent_free (me=0xcf28c06c)
    at /src/src/sys/uvm/uvm_map.c:733

The flags of the entry to be freed are 0x11, i.e. UVM_MAP_NOMERGE | 

#8 0xc04da5b7 in uvm_map_replace (map=0xc0d0dae0, start=3475865600, end=3475869696, newents=0xdd853644, nnewents=1)
    at /src/src/sys/uvm/uvm_map.c:2540

The map in which to replace the stuff is the _same_ as the one used for the ukh,
i.e. the kernel map.  That's why the map is already locked (as neccessary
according to the comment above the routine.)

#9 0xc04dae28 in uvm_map_extract (srcmap=0xcdadb55c, start=3217027072, len=4096, dstmap=0xc0d0dae0, dstaddrp=0xcf94ab18, flags=14)
    at /src/src/sys/uvm/uvm_map.c:2854

Acording to the comment above the routine:
        map should be unlocked (we will write lock them)
So the destination map (i.e. kernel_map) is locked here before uvm_map_replace
gets called.

#10 0xc04d2bc3 in uvm_io (map=0xcdadb55c, uio=0xcf94ab8c)
    at /src/src/sys/uvm/uvm_io.c:108

Here we supply an explicit kernel_map as the destination map on the call to

#11 0xc0524fe2 in sysctl_kern_proc_args (name=0xcf94ac9c, namelen=2, oldp=0xbb915080, oldlenp=0xcf94ac90, newp=0x0, newlen=0, oname=0xcf94ac94, l=0xcf9232e0, rnode=0xc4097f60) at /src/src/sys/kern/init_sysctl.c:2486 #12 0xc055aff7 in sysctl_dispatch (name=0xcf94ac94, namelen=4, oldp=0xbb915080, oldlenp=0xcf94ac90, newp=0x0, newlen=0, oname=0xcf94ac94, l=0xcf9232e0, rnode=0xc4097f60) at /src/src/sys/kern/kern_sysctl.c:446 #13 0xc055ac4a in sys___sysctl (l=0xcf9232e0, uap=0xcf94ad04, retval=0xcf94acfc) at /src/src/sys/kern/kern_sysctl.c:302
#14 0xc065d7b1 in syscall (frame=0xcf94ad48)
    at /src/src/sys/arch/i386/i386/syscall.c:112
#15 0xc0100574 in syscall1 ()

So anyone out there who knows how this is supposed to work?  To me it looks
as though you'd have to be lucky to avoid the ukh->ukn_nused <= 1 case in
uvm_kmapent_free.  Or am I missing something?


Home | Main Index | Thread Index | Old Index