* Alfred Perlstein <[EMAIL PROTECTED]> [020326 14:43] wrote: > * Kris Kennaway <[EMAIL PROTECTED]> [020324 14:26] wrote: > > The bento cluster is now running with WITNESS enabled to try and track > > down some odd UMA lock corruption panics. Instead, it found the > > following lock order reversal in sys_pipe.c overnight: > > > > Mar 24 09:02:29 <user.crit> gohan13 kernel: lock order reversal > > Mar 24 09:02:29 <user.crit> gohan13 kernel: 1st 0xd99d6500 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 09:02:29 <user.crit> gohan13 kernel: 2nd 0xd971cddc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > > > Those source references are from a -current kernel from last night. > > Are you %100 on that? How did you get this to happen? > > I can see where I hold the pipe lock, then try to get a proc lock, > but not the other way around... > > Any ideas?
Note that I can pretty trivially fix this by dropping the pipe lock while calling pgsigio in pipeselwakeup(), however I will then have to make sure the callers of pipeselwakeup() can deal with someone else mucking with the pipe during the call. Anyhow, wtf doesn't witness print out at least one instance of the old locking? Basically let me know where locking is happening in the other direction? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message