Date: Mon, 21 Oct 2002 20:55:56 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: rwatson@FreeBSD.ORG Cc: larse@ISI.EDU, current@FreeBSD.ORG Subject: Re: yet another lock order reversal Message-ID: <200210220356.g9M3tuvU078298@gw.catspoiler.org> In-Reply-To: <Pine.NEB.3.96L.1021021233800.83141a-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210220356.g9M3tuvU078298>