Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 May 2016 20:39:32 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        cem@freebsd.org
Cc:        "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: KASSERT: always assert; KWARN
Message-ID:  <CAJ-VmokyEnAEGPuqj7b_V5RPFxQ3XfoFOu%2BiVYpejTdMH%2B-5Pw@mail.gmail.com>
In-Reply-To: <CAG6CVpWzuK6cZx3QnQhKOu=6GZBJF4cJQdNXgJZeXYhuJJANJg@mail.gmail.com>
References:  <CAG6CVpWzuK6cZx3QnQhKOu=6GZBJF4cJQdNXgJZeXYhuJJANJg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
i found it very useful to get asserts to print, rather than panic.



-a


On 10 May 2016 at 18:24, Conrad Meyer <cem@freebsd.org> wrote:
> I'd like to logically revert r243980 and r244105, such that KASSERT
> uses the __dead2-annotated panic(9).
>
> Going back to the old behavior enables Coverity and other static
> analyzers to reason about KASSERT invariants via the __dead2 panic(9)
> path.
>
> This proposal is in https://reviews.freebsd.org/D6117 .
>
> As a follow-up, to match the assumed intent of the r243980 changes, I
> propose a KWARN facility which may be muted, rate limited, or even
> cause panic.  Generally, KASSERTs should not be KWARNs.  That proposal
> is here: https://reviews.freebsd.org/D6134
>
> Finally, I am looking for suggestions of things it *does* make sense
> to KWARN about.  One suggestion was witness_warn; however, it doesn't
> seem like a great fit (without adding allocating sbufs in, anyway).  A
> sketch of that is in https://reviews.freebsd.org/D6306 .
>
> Thoughts or objections?  Does anyone like the ability to opt out of
> invariants asserts?
>
> Best,
> Conrad
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokyEnAEGPuqj7b_V5RPFxQ3XfoFOu%2BiVYpejTdMH%2B-5Pw>