Date: Mon, 20 Jul 2015 11:04:58 -0700 From: John Baldwin <jhb@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Sean Bruno <sbruno@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285639 - head/sys/dev/e1000 Message-ID: <1772930.9D9KgtoGqa@ralph.baldwin.cx> In-Reply-To: <20150717030840.B3034@besplex.bde.org> References: <201507161632.t6GGWwJA072336@repo.freebsd.org> <20150717030840.B3034@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1772930.9D9KgtoGqa>