Re: "locking against myself" panic, apparently from nfs_rcvlock()

[mlelstv%serpens.de@localhost (Michael van Elst)]

woods%planix.ca@localhost ("Greg A. Woods") writes:

>I found this on the console:

>[ 6123.1695877] panic: lock error: Mutex: mutex_vector_enter,551: locking against myself: lock 0xffff8c800d63e280 cpu 0 lwp 0xffff8c800c922000
>[ 6123.1695877] cpu0: Begin traceback...
>[ 6123.1695877] vpanic() at netbsd:vpanic+0x164
>[ 6123.1695877] panic() at netbsd:panic+0x3c
>[ 6123.1695877] lockdebug_abort() at netbsd:lockdebug_abort+0x10f
>[ 6123.1695877] mutex_vector_enter() at netbsd:mutex_vector_enter+0x2f5
>[ 6123.1695877] sigpending1() at netbsd:sigpending1+0x24
>[ 6123.1695877] nfs_rcvlock() at netbsd:nfs_rcvlock+0xed
>[ 6123.1695877] nfs_request() at netbsd:nfs_request+0x48e
>[ 6123.1817135] nfs_access() at netbsd:nfs_access+0x30b
>[ 6123.1817135] VOP_ACCESS() at netbsd:VOP_ACCESS+0x55
>[ 6123.1817135] getcwd_common() at netbsd:getcwd_common+0x2bd
>[ 6123.1817135] vnode_to_path() at netbsd:vnode_to_path+0xbb
>[ 6123.1817135] sysctl_vmproc() at netbsd:sysctl_vmproc+0x71c



sysctl_vmproc
-> fill_vmentries (takes p->p_lock)
   -> fill_vmentry
      -> vnode_to_path
         -> getwd_common
            -> VOP_ACCESS
               ...   sigpending1 (wants p->p_lock)


Calling into VFS layer while holding a process lock is not
the best idea.