From owner-freebsd-current Mon Sep 30 22:45:46 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 8EB2C37B401; Mon, 30 Sep 2002 22:45:45 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C6D043E3B; Mon, 30 Sep 2002 22:45:45 -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 g915jYvU012168; Mon, 30 Sep 2002 22:45:38 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210010545.g915jYvU012168@gw.catspoiler.org> Date: Mon, 30 Sep 2002 22:45:34 -0700 (PDT) From: Don Lewis Subject: Re: World broken at libkvm To: jmallett@FreeBSD.ORG, freebsd-current@FreeBSD.ORG In-Reply-To: <20021001035729.D34502A88D@canning.wemm.org> 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 30 Sep, Peter Wemm wrote: > Juli Mallett wrote: >> And now fixed. All we have to look out for now is someone doing something >> that exposes some sort of functional difference, but I don't anticipate it. > I suggest you turn WITNESS on, and stress the system. If you get *new* > 'could sleep' stuff or other lock order problems, then there are still > significant regressions to be fixed. The last thing we need during the > 'please stabilize 5.0' drive is newly added problems. If other folks are > seeing new ones, please report them here (not to me, I already get too much > email :-]). I suggest looking especially closely at the sigio stuff. Even the old code has a lock order reversal problem when I/O to a pipe wants to signal the process at the other end of the pipe. I thought a lot about that problem and never found a clean fix. The sigio stuff could be even nastier if you need to allocate memory in the signal code because the sigio can be invoked by the reception of a packet from the network, which is not handled in a process context ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message