From owner-cvs-all@FreeBSD.ORG Fri Nov 14 11:03:18 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8226616A4CF for ; Fri, 14 Nov 2003 11:03:18 -0800 (PST) Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6C043FBF for ; Fri, 14 Nov 2003 11:03:15 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 23305 invoked from network); 14 Nov 2003 19:03:14 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Nov 2003 19:03:14 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hAEJ3BEW007234; Fri, 14 Nov 2003 14:03:11 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 14 Nov 2003 14:03:08 -0500 (EST) From: John Baldwin To: John Baldwin X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/sys proc.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 19:03:18 -0000 On 14-Nov-2003 John Baldwin wrote: > > On 14-Nov-2003 John Baldwin wrote: >> jhb 2003/11/14 08:27:17 PST >> >> FreeBSD src repository >> >> Modified files: >> sys/sys proc.h >> Log: >> Add a WITNESS_WARN() check to _STOPEVENT() since any _STOPEVENT() can >> potentially sleep. This should help find some bogus locking. > > There is at least one place where sigacts locking trips this assertion. > I will try to work on cleaning up that and other problems that surface > today from this check. > > I also need to add a KASSERT() to msleep/cv_wait* that we don't try > to sleep if we are already on a sleep queue. It seems that using > ptrace can trip that as well. :( Also, this last is also a bug in 4.x, though I think perhaps it is a feature. Basically, in msleep() in both branches, we put a thread/proc on the sleep queue before checking for signals(). If during checking signals we are woken up, we don't sleep but return immediately. Thus, if during checking for signals we sleep because of a stop event, we just won't ever sleep on the original wait channel but will return to recheck the condition in a while loop. However, I am curious if the linkages of the sleep queues can be broken by taking a thread that is already on a sleep queue and sticking it on another sleep queue. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/