KASSERT_WARN for asserting malloc(M_WAITOK) not in a non-sleepable thread

[NGie Cooper]

On Wed, Sep 24, 2014 at 7:56 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Wed, Sep 24, 2014 at 6:16 PM, Bryan Drewery <bdrewery at freebsd.org> wrote:
>> Hi,
>>
>> I've placed 2 reviews out in relation to
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193696:
>>
>> Add KASSERT_WARN which will work just like KASSERT except that no panic
>> will occur.  My own expectation would be that any use of it would
>> eventually be promoted to a full KASSERT.  It would only be used where
>> the impact is not known yet on all hardware/devices.  We don't want to
>> go adding a KASSERT and break boot for a whole class of systems.
>>
>>   https://reviews.freebsd.org/D829 - KASSERT_WARN
>
> FYI, I'm not excited about the idea. If you introduce an assert you
> want some invariant to not be violated. If it's violated, there's
> something clearly going wrong and you need to stop and think about it.
> I guess that in most cases is just better fail early, rather than keep
> going with the system in a semi-functional state.  Also, please note
> that once a KPI is introduced in the kernel, everybody may start
> abusing it.
> A previous attempt (in my opinion wrong) was made to have KASSERT to
> log rather than panic. It actually didn't lead to any benefit,
> apparently. FWIW, at least your approach is more fine grained.

The probability of hitting bug 193696 is unknown but the potential
impact is great, so until most of the code paths are fixed and/or we
have enough data to quantify the impact (and the data suggests that
the probability is in fact low), it would be unadvisable to replace
the KASSERT_WARN Bryan's introducing with a KASSERT. Eventually it
should probably turn into a KASSERT.

I agree that developers should use KASSERT_WARN sparingly and
carefully. Maybe a comment should be added to note that?

Thanks!
-Garrett