From owner-svn-src-all@FreeBSD.ORG Sat Dec 22 09:51:52 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6E96716; Sat, 22 Dec 2012 09:51:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 57FE48FC13; Sat, 22 Dec 2012 09:51:51 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBM9pmxr019818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Dec 2012 20:51:49 +1100 Date: Sat, 22 Dec 2012 20:51:47 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Attilio Rao Subject: Re: svn commit: r244582 - head/sys/kern In-Reply-To: <201212220937.qBM9bYQK050680@svn.freebsd.org> Message-ID: <20121222204409.V1410@besplex.bde.org> References: <201212220937.qBM9bYQK050680@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Zvi1sKHG c=1 sm=1 a=psoCjdI5atsA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=M4roAWbnUW4A:10 a=I82O9co9HvBKwmjKFJcA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 09:51:52 -0000 On Sat, 22 Dec 2012, Attilio Rao wrote: > Log: > Fixup r240424: On entering KDB backends, the hijacked thread to run > interrupt context can still be idlethread. At that point, without the > panic condition, it can still happen that idlethread then will try to > acquire some locks to carry on some operations. > > Skip the idlethread check on block/sleep lock operations when KDB is > active. This seems backwards to me. It is an error to go near normal locking code when kdb is active. > Modified: head/sys/kern/kern_lock.c > ============================================================================== > --- head/sys/kern/kern_lock.c Sat Dec 22 07:48:09 2012 (r244581) > +++ head/sys/kern/kern_lock.c Sat Dec 22 09:37:34 2012 (r244582) > @@ -35,6 +35,7 @@ > __FBSDID("$FreeBSD$"); > > #include > +#include > #include > #include > #include > @@ -477,7 +478,7 @@ __lockmgr_args(struct lock *lk, u_int fl > KASSERT((flags & LK_INTERLOCK) == 0 || ilk != NULL, > ("%s: LK_INTERLOCK passed without valid interlock @ %s:%d", > __func__, file, line)); > - KASSERT(!TD_IS_IDLETHREAD(curthread), > + KASSERT(kdb_active != 0 || !TD_IS_IDLETHREAD(curthread), > ("%s: idle thread %p on lockmgr %s @ %s:%d", __func__, curthread, > lk->lock_object.lo_name, file, line)); This is backwards from: KASSERT(kdb_active == 0); which makes it fatal for any thread to call here. Of course, bugs in this area are common. Last time I tried checking for them, I only used db_printfs() in places like _mtx_lock_flags(), and had to turn off the printfs since they occurred too often. WIthout assertions to inhibit them, these bugs must be more common now. Bruce