svn commit: r332860 - head/sys/kern

Jonathan Looney jonlooney at gmail.com
Sat Apr 21 20:33:36 UTC 2018


On Sat, Apr 21, 2018 at 1:53 PM, Conrad Meyer <cem at freebsd.org> wrote:
>
> I don't think this should be enabled by default.  Can we leave it
> disabled by default and let consumers opt-in?

I'm willing to change the default if there's a good reason or consensus for
that. However, it is not obvious to me that the default is actually wrong.

I think its important that we remember where we are when we hit this code.

By the time we hit this code, we've already panic'd (whether due to a
"true" panic or a violated assertion). At this point, the system is already
in an unknown/unexpected state and we want to preserve our ability to
troubleshoot and/or recover. (And, since we're running a system with
INVARIANTS, presumably the ability to troubleshoot is important.)

We may well violate a second assertion simply because the system is in an
unknown/unexpected state. Once we do that, the question is whether we
should try to preserve the ability to troubleshoot, or should give up and
reset the system.

All too often, my ability to debug assertion violations is hindered because
the system trips over yet another assertion while dumping the core. If we
skip the assertion, nothing bad happens. (The post-panic debugging code
already needs to deal with systems that are inconsistent, and it does a
pretty good job at it.)

On the other hand, I really am not sure what you are worried might happen
if we skip checking assertions after we've already panic'd. As far as I can
tell, the likely worst case is that we hit a true panic of some kind. In
that case, we're no worse off than before.

I think the one obvious exception is when we're purposely trying to
validate the post-panic debugging code. In that case, you can change the
sysctl/tunable to enable troubleshooting.

I would honestly appreciate someone explaining the dangers in disabling a
response to assertion violations after we've already panic'd and are simply
trying to troubleshoot, because they are not obvious to me. But, I could
simply be missing them.

Jonathan


More information about the svn-src-all mailing list