svn commit: r244582 - head/sys/kern

[Bruce Evans]

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 <sys/param.h>
> +#include <sys/kdb.h>
> #include <sys/ktr.h>
> #include <sys/lock.h>
> #include <sys/lock_profile.h>
> @@ -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