From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 18:40:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B820210656B8; Fri, 2 Dec 2011 18:40:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3338FC20; Fri, 2 Dec 2011 18:40:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 2809E46B0A; Fri, 2 Dec 2011 13:40:14 -0500 (EST) Received: from John-Baldwins-MacBook-Air.local (c-68-36-150-83.hsd1.nj.comcast.net [68.36.150.83]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 983A7B926; Fri, 2 Dec 2011 13:40:13 -0500 (EST) Message-ID: <4ED91B8D.2080808@FreeBSD.org> Date: Fri, 02 Dec 2011 13:40:13 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201112011349.50502.jhb@freebsd.org> <4ED7E6B0.30400@FreeBSD.org> <201112011553.34432.jhb@freebsd.org> <4ED7F4BC.3080206@FreeBSD.org> <4ED855E6.20207@FreeBSD.org> <4ED8A306.9020801@FreeBSD.org> <4ED8F1C1.7010206@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 02 Dec 2011 13:40:13 -0500 (EST) Cc: freebsd-current@freebsd.org, Konstantin Belousov , Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:40:14 -0000 On 12/2/11 12:18 PM, Attilio Rao wrote: > 2011/12/2 John Baldwin: >> On 12/2/11 5:05 AM, Andriy Gapon wrote: >>> >>> on 02/12/2011 06:36 John Baldwin said the following: >>>> >>>> Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when >>>> kdb was >>>> active). But I think these two changes should cover critical_exit() ok. >>>> >>> >>> I attempted to start a discussion about this a few times already :-) >>> Should we treat kdb context the same as SCHEDULER_STOPPED context (in the >>> current definition) ? That is, skip all locks in the same fashion? >>> There are pros and contras. >> >> >> kdb should not block on locks, no. Most debugger commands should not go >> near locks anyway unless they are intended to carefully modify the existing >> system in a safe manner (such as the 'kill' command which should only be >> using try locks and fail if it cannot safely post the signal). > > The biggest problem to KDB as the same as panic is that doing proper > 'continue' is impossible. > One of the features of the 'skip-locking' path is that it doesn't take > into account fast locking paths, where sometimes the lock can succeed > and other fails and you don't know about them. Also the restarted CPUs > can find corrupted datas (as they can be arbitrarely updated), I'm > sure it is too much panic prone. Yes, my thought is that kdb commands, etc. should be using dedicated routines that do not use locks whenever possible. The problem of a user calling an arbitrary routine is not solvable (so I don't think we should try to solve that, you use 'call' at your own risk), but built-in commands should explicitly either 1) not use locking, or 2) only use try locks and fail out cleanly (including dropping any try locks acquired) if a try fails. Now, that's an ideal view, I don't know how close we are to that in practice or if it is a realistically attainable goal. -- John Baldwin