Date: Tue, 8 Oct 2002 21:41:52 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jhb@FreeBSD.org Cc: arch@FreeBSD.org, jmallett@FreeBSD.org Subject: Re: [jmallett@FreeBSD.org: [PATCH] Reliable signal queues, etc., Message-ID: <200210090441.g994fqvU037422@gw.catspoiler.org> In-Reply-To: <XFMail.20021008101429.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210090441.g994fqvU037422>