From owner-freebsd-arch Tue Oct 8 21:42: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 713FC37B401; Tue, 8 Oct 2002 21:42:01 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F02A443E4A; Tue, 8 Oct 2002 21:42:00 -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 g994fqvU037422; Tue, 8 Oct 2002 21:41:56 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200210090441.g994fqvU037422@gw.catspoiler.org> Date: Tue, 8 Oct 2002 21:41:52 -0700 (PDT) From: Don Lewis Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., To: jhb@FreeBSD.org Cc: arch@FreeBSD.org, jmallett@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8 Oct, John Baldwin wrote: > > On 08-Oct-2002 Don Lewis wrote: >> It looks like we've got a potential lock order reversal problem, though. >> In fork1() we grab ppeers_lock while holding a couple of PROC_LOCKs, >> while in the first part of exit1() we grab ppeers_lock before PROC_LOCK. >> My caffeine level is insufficient to judge whether P_WEXIT checking >> would save us in practice. > > Bah, fixed the reversal, thanks. We still need the P_WEXIT check in > fork1() since otherwise a new peer or child could be added after we > have finished going through the entire list. Hmm, adding this is ugly > though b/c we really need to check after we acquire the ppeers_lock and > do the actual hookup. Hmm, we can move the RFTHREAD stuff a lot earlier > and then this isn't such a big deal. Ok, I've updated the patch again. Looks good. > One note: I've got a question about how to handle the error condition > in that case in fork1(). I'm really starting to think that instead of > returning an error, the peer process should just go ahead and call > exit1() in this case since it is about to be killed anyways. I pretty much agree. I would worry about the process doing something bogus based on the wierd error returned by fork() before it is finally killed off. Calling exit1() from within fork() is kind of icky, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message