Date: Thu, 18 Jun 2009 16:54:02 -0400 From: John Baldwin <jhb@freebsd.org> To: Mel Flynn <mel.flynn+fbsd.hackers@mailing.thruhere.net> Cc: freebsd-hackers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: How best to debug locking/scheduler problems Message-ID: <200906181654.02970.jhb@freebsd.org> In-Reply-To: <200906171411.42957.mel.flynn%2Bfbsd.hackers@mailing.thruhere.net> References: <200906151353.06630.mel.flynn%2Bfbsd.hackers@mailing.thruhere.net> <200906171717.37677.jhb@freebsd.org> <200906171411.42957.mel.flynn%2Bfbsd.hackers@mailing.thruhere.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906181654.02970.jhb>