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

[Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>]

The following reply was made to PR kern/38415; it has been noted by GNATS.

From: Wolfgang Solfrank <Wolfgang%Solfrank.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/38415: sysctl panic: locking against myself
Date: Thu, 17 Apr 2008 18:23:19 +0200

 Hi,
 
 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 | 
UVM_MAP_KERNEL.
 
 > #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
 uvm_map_extract.
 
 > #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 ()
 > (gdb) 
 
 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?
 
 Ciao,
 Wolfgang
 -- 
 Wolfgang%Solfrank.net@localhost