Date: Sat, 21 Apr 2018 10:53:41 -0700 From: Conrad Meyer <cem@freebsd.org> To: "Jonathan T. Looney" <jtl@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332860 - head/sys/kern Message-ID: <CAG6CVpVAKAou%2B=9dv%2Bef8txmykR%2BMCpbmvteJua7ErhXvM7rCg@mail.gmail.com> In-Reply-To: <201804211705.w3LH50Dk056339@repo.freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Sat, Apr 21, 2018 at 10:05 AM, Jonathan T. Looney <jtl@freebsd.org> wrote: > Author: jtl > Date: Sat Apr 21 17:05:00 2018 > New Revision: 332860 > URL: https://svnweb.freebsd.org/changeset/base/332860 > > Log: > When running with INVARIANTS, the kernel contains extra checks. However, > these assumptions may not hold true once we've panic'd. Therefore, the > checks hold less value after a panic. Additionally, if one of the checks > fails while we are already panic'd, this creates a double-panic which can > interfere with debugging the original panic. > > Therefore, this commit allows an administrator to suppress a response to > KASSERT checks after a panic by setting a tunable/sysctl. The > tunable/sysctl (debug.kassert.suppress_in_panic) defaults to being > enabled. Hi Jonathan, I don't think this should be enabled by default. Can we leave it disabled by default and let consumers opt-in? To expand on this a little: this is a big hammer. We already disable specific invariants in a few cases during panic (lock assertions come to mind). If there are specific assertions that do not hold during panic, we can/should selectively weaken them. But in general, invariants are invariant, and we should not proceed past violated ones by default. Thanks, Conradhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVAKAou%2B=9dv%2Bef8txmykR%2BMCpbmvteJua7ErhXvM7rCg>