Date: Sat, 22 Dec 2012 20:51:47 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r244582 - head/sys/kern Message-ID: <20121222204409.V1410@besplex.bde.org> In-Reply-To: <201212220937.qBM9bYQK050680@svn.freebsd.org> References: <201212220937.qBM9bYQK050680@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121222204409.V1410>