svn commit: r285639 - head/sys/dev/e1000

[John Baldwin]

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