How best to debug locking/scheduler problems

[John Baldwin]

On Wednesday 17 June 2009 6:11:42 pm Mel Flynn wrote:
> On Wednesday 17 June 2009 13:17:37 John Baldwin wrote:
> > These are the key frames.  It looks like uipc_peeraddr() tries to lock two
> > unp locks w/o any protection from the global unp linkage lock.  I've
> > changed it to use the same locking as uipc_accept() where it first grabs a
> > read lock on the linkage lock and then just locks the other end of the
> > connection to copy out its sockaddr.
> 
> Thanks John. I'll recompile the kernel with patch and up-to-date current and 
> report back if there are any side effects or if the bug resurfaces.
> Is there a sure way (i.e. testcase) that would expose this condition? At 
> present, all I can do is wait and maybe play with network interface link 
> up/down, as it seems to be related from a high level view.

I write a testcase for this that had two threads calling getpeername() against 
each other in a loop.  It locked up on a stock 7.x box in a few seconds. :)  
It has run to completion without deadlocking with the patch.

-- 
John Baldwin