From owner-freebsd-arch@FreeBSD.ORG  Fri Dec  7 18:31:10 2012
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id F19CB675;
 Fri,  7 Dec 2012 18:31:09 +0000 (UTC) (envelope-from bright@mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
 by mx1.freebsd.org (Postfix) with ESMTP id D0A9E8FC12;
 Fri,  7 Dec 2012 18:31:09 +0000 (UTC)
Received: from Alfreds-MacBook-Pro-6.local
 (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218])
 by elvis.mu.org (Postfix) with ESMTPSA id 880C81A3CD6;
 Fri,  7 Dec 2012 10:31:09 -0800 (PST)
Message-ID: <50C235EC.2050903@mu.org>
Date: Fri, 07 Dec 2012 10:31:08 -0800
From: Alfred Perlstein <bright@mu.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Adrian Chadd <adrian@freebsd.org>
Subject: Re: svn commit: r243980 - in head/sys: kern sys
References: <201212070825.qB78P9rY055786@svn.freebsd.org>
 <CAJ-Vmo=f5fxFzVOUWcXE6GxovH3kTB-UmEkuWc5CkK0ZU+QKpA@mail.gmail.com>
In-Reply-To: <CAJ-Vmo=f5fxFzVOUWcXE6GxovH3kTB-UmEkuWc5CkK0ZU+QKpA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2012 18:31:10 -0000

On 12/7/12 6:25 AM, Adrian Chadd wrote:
> Ok, so can we now please split 'panic during debugging but we do
> handle the case' and 'panic during live runs as it really does mean
> we're hosed' assert checks, so coders can choose which is appropriate?
>
> Or does that now exist?

I'm not sure I'm understanding the requirement.

We have places in the code that explicitly call panic that I know of 
that a KASSERT is not right because if the condition is caught then the 
kernel will die badly.

Example (from subr_turnstile.c):

>                 /*
>                  * If the thread is asleep, then we are probably about
>                  * to deadlock.  To make debugging this easier, just
>                  * panic and tell the user which thread misbehaved so
>                  * they can hopefully get a stack trace from the truly
>                  * misbehaving thread.
>                  */
>                 if (TD_IS_SLEEPING(td)) {
>                         printf(
>                 "Sleeping thread (tid %d, pid %d) owns a non-sleepable 
> lock\n",
>                             td->td_tid, td->td_proc->p_pid);
>                         kdb_backtrace_thread(td);
>                         panic("sleeping thread");
>                 }

Or do you mean something else?

Propose an API! :)  Let's see where this goes.

-Alfred