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
