svn commit: r244112 - head/sys/kern

[Andriy Gapon]

on 12/12/2012 23:58 John Baldwin said the following:
> Hmmm, I'll have to chew on this.  Adding lots of returns because panic's are
> now no longer dead2 was why I ended up backing the removal of the
> RESTARTABLE_PANICS option.
> 
> I'm inclined to say that it's really bad to let a kernel known to be in a
> bad state continue, and that if someone has asked for the slowdown of all
> the extra checks INVARIANTS adds, they might as well minimize the chance for
> data corruption by having the kernel stop as soon as a problem is detected.
> 
> (Note that the primary reason I know for people not running with INVARIANTS
> enabled is not that they don't want panics, but that they don't want the
> performance hit.)

Previously we had two alternatives:
- use INVARIANTS and be sure that the kernel is in sane state, that any bugs are
caught early, no corruptions / insanity is propagated to the point where
valuable data can be hurt; the price is lower (possibly much lower) performance
because of all other checks;
- do not use INVARIANTS and risk that some error would not be caught early and
would cause greater harm; the upside is better performance;

So people used (use) INVARIANTS to extensively test any new code/environments,
but then prefer to run production systems without INVARIANTS.

Now we get a new middle-ground: get both worse performance (because KASSERTs are
compiled in) and a risk of harming your data (because KASSERTs no longer panic).
 The upside: there is no panic!  There's just a log message (or etc).  and
chance to get more log messages because the insanity propagates.  And a chance
to lose your data (your customer's) - but I've already mentioned this.

I am not sure that I like this kind of middle-ground.

-- 
Andriy Gapon