From owner-svn-src-head@freebsd.org Tue Jul 21 01:41:57 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BDD19A735B; Tue, 21 Jul 2015 01:41:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 686C99A3; Tue, 21 Jul 2015 01:41:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6EE5FB913; Mon, 20 Jul 2015 21:41:56 -0400 (EDT) From: John Baldwin To: Bruce Evans Cc: Sean Bruno , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285639 - head/sys/dev/e1000 Date: Mon, 20 Jul 2015 11:04:58 -0700 Message-ID: <1772930.9D9KgtoGqa@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150717030840.B3034@besplex.bde.org> References: <201507161632.t6GGWwJA072336@repo.freebsd.org> <20150717030840.B3034@besplex.bde.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 Jul 2015 21:41:56 -0400 (EDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 01:41:57 -0000 On Friday, July 17, 2015 03:45:36 AM Bruce Evans wrote: > On Thu, 16 Jul 2015, Sean Bruno wrote: > > > Log: > > Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS > > panic in em_init_locked() while debugging. > > It is a bug to lock anything from within ddb. Agreed. DDB commands should avoid locking. If anything what you might do is use a try lock and fail the request if having the lock held means you can't safely proceed (this is what the 'kill' command in DDB does/did). If you are fine with waiting for a lock, then you shouldn't do this in DDB at all, but perhaps add a dev.em.X.reset sysctl node that does the reset when it is set to a non-zero value. (You could set CTLFLAG_SKIP to hide it from sysctl -a if desired.) If you truly need a sledgehammer that works from DDB, then locking is the last thing you want to add. I would just ignore the witness warning if possible. Alternatively you can just hack the driver to not do any locking when kdb_active is true. Your current change means that if the lock is held when you enter DDB and run the command your machine probably hard hangs. If you instead disable locking by checking kdb_active then if you drop into DDB while the lock is held you might surprise the interrupted code, but you will always get a DDB prompt back after you run the command. If surprising the interrupting code is too disruptive, then use a try lock and fail the command if the lock is held. -- John Baldwin