On 12/2/11 12:18 PM, Attilio Rao wrote:
2011/12/2 John Baldwin<j...@freebsd.org>:
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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
