Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Dec 2011 10:41:53 -0500
From:      John Baldwin <jhb@FreeBSD.org>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Stop scheduler on panic
Message-ID:  <4ED8F1C1.7010206@FreeBSD.org>
In-Reply-To: <4ED8A306.9020801@FreeBSD.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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).

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED8F1C1.7010206>