svn commit: r244112 - head/sys/kern

[Adrian Chadd]

On 16 December 2012 15:32, Navdeep Parhar <nparhar at gmail.com> wrote:


>> The status quo _does not change_ by default.
>
> So now we have a knob that could be used to change the behaviour of all
> the KASSERTs in the system; one that hints that it may be possible to
> continue even if an assertion in the FreeBSD kernel doesn't hold good
> (this is the part that bothers me).  I know all the KASSERTs I've looked
> at or written are genuine assertions -- the code simply wouldn't be able
> to cope if they were violated.  You'd get NULL dereferences, or worse,
> access protected structures without corresponding locks held, etc.

In that case, those failures should be handled gracefully, or they
should immediately panic the kernel.

Claiming that a KASSERT() is optional at this point is basically us as
a project saying "We know that if the kernel gets to this point and it
fails this check, everything is busted after this." Ie, "Hey, if you
disable KASSERT(), your data is potentially toast."

Yet we ship with KASSERT() disabled. Silent data corruption, race
conditions, etc. Not everything leads to a NULL pointer dereference.

Again, we ship with KASSERT disabled in GENERIC on shipping production
releases. The concerns you have with KASSERT printing out when
Alfred's modification is enabled -does not change the fact that the
kernel does _EXACTLY THIS_ kind of "oh well, I'll keep going"
behaviour in a GENERIC, production, release kernel-.




Adrian