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) @ 
>> Jul  7 07:47:09 scratch kernel: 2nd 0xc0474300 sigio lock (sigio lock) @ 
> 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

Reply via email to