On 21 Oct, Robert Watson wrote:
>
> On Mon, 21 Oct 2002, Lars Eggert wrote:
>
>> lock order reversal
>> 1st 0xc791bc00 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465
>> 2nd 0xc04974e0 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2156
>
> It strikes me that, for better or for worse, the reported "reversal" is
> the right way around, and the prior access was the wrong one. It may be
> possible to extract the locking locations of the prior order using 'show
> witness' in ddb.
I did that back in July and posted it to the list:
sigio -> process group -> process -> filedesc -> pipe
The recent locking changes in the kqueue code run into the same problem.
I think it is probably easier to fix this in the pipe code by dropping
the pipe lock before calling pipeselwakeup() and relocking afterwards if
necessary. The nasty bits are recovering if another process mucks with
the pipe while the lock was dropped and figuring out how to rejigger the
locking of the pipe_state flags that pipeselwakeup() plays with.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
