On 11 Jul, Don Lewis wrote: > On 7 Jul, Don Lewis wrote: >> Jul 7 07:47:09 scratch kernel: lock order reversal >> Jul 7 07:47:09 scratch kernel: 1st 0xcabf7980 pipe mutex (pipe mutex) @ >/usr/src/sys/kern/sys_pipe.c:451 >> Jul 7 07:47:09 scratch kernel: 2nd 0xc0474300 sigio lock (sigio lock) @ >/usr/src/sys/kern/kern_sig.c:2113> > > I figured out part of the problem. The call stack is: > > pgsigio() > pipe_read() > dofileread() > read() > > This was a bit tricky to find because the call to pgsigio() is hidden > in pipeselwakeup(), which is an inline function called by pipe_read(). > > I don't see a good way to fix this. I also don't yet know why > witness thinks it has seen the locks asserted in the opposite order.
I got the serial console stuff set up and did a "show witness" to find the conflicting lock order: sigio -> process group -> process -> filedesc -> pipe I think the best fix is to defer calling pgsigio until after the pipe lock is released, but this looks like a messy change. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message