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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
