From owner-freebsd-current Mon Oct 21 20:56:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CB1837B401; Mon, 21 Oct 2002 20:56:16 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D1F843E6E; Mon, 21 Oct 2002 20:56:10 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g9M3tuvU078298; Mon, 21 Oct 2002 20:56:01 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210220356.g9M3tuvU078298@gw.catspoiler.org> Date: Mon, 21 Oct 2002 20:55:56 -0700 (PDT) From: Don Lewis Subject: Re: yet another lock order reversal To: rwatson@FreeBSD.ORG Cc: larse@ISI.EDU, current@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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