From owner-svn-src-all@freebsd.org Sat Apr 21 17:53:49 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED886FB67E7; Sat, 21 Apr 2018 17:53:48 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88B7B6A303; Sat, 21 Apr 2018 17:53:48 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f46.google.com with SMTP id u62-v6so6042539ita.5; Sat, 21 Apr 2018 10:53:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=gmEOZhUas7+Jr1TXOutPCyWtThxkIkjbET9E1YpwAIE=; b=E8UUb33a0iO21SlA6AZ+NtQ6XuXd3hgyyzjv0viJF4xG701kF2mazhleVLpkcfFX9s WTFOWuOHgWq9lgsGwWaay41pmf5Mtiw9oCNnlQ0oGGRmW1ND415zr9/r9rky4cVVn5ej G83oRdoHVWI32ZHrg4Z8gez8++VTKHyzxs6msywTkvichoA5zDfEKyYI0Zuunipq33Xx fuMqnfIPydBQ8tjqxuXw9GYmNOcVM4d3FGCe27V9PDPI88rwkiR6ble+sDlxEhi/BtbN M3Nnis3hDPrg9fbqc3iL3XkjYdLjHFK0g79Z2yzaq7oNa0FENIbWj/4hd5lV+4SvHLnh 6PNw== X-Gm-Message-State: ALQs6tC1xloGatvc5thvOlWKp3fEd2OzKQqw56lqCb9CqPjgYC7dJAlg C3eVC4PSIqj+zCFzobYLjv787dSU X-Google-Smtp-Source: AIpwx49fn3rXj+12z9Ax1Q06eMg6an2xMD7hgM832hMGUjIr85kwNw9ovfoew/SYHpGTHpINNz7GsA== X-Received: by 2002:a24:2ec8:: with SMTP id i191-v6mr7532840ita.149.1524333222307; Sat, 21 Apr 2018 10:53:42 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id s142-v6sm2144368itb.4.2018.04.21.10.53.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 10:53:41 -0700 (PDT) Received: by mail-io0-f172.google.com with SMTP id d26-v6so13956652ioc.2; Sat, 21 Apr 2018 10:53:41 -0700 (PDT) X-Received: by 2002:a6b:da04:: with SMTP id x4-v6mr6398772iob.19.1524333221780; Sat, 21 Apr 2018 10:53:41 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:224d:0:0:0:0:0 with HTTP; Sat, 21 Apr 2018 10:53:41 -0700 (PDT) In-Reply-To: <201804211705.w3LH50Dk056339@repo.freebsd.org> References: <201804211705.w3LH50Dk056339@repo.freebsd.org> From: Conrad Meyer Date: Sat, 21 Apr 2018 10:53:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r332860 - head/sys/kern To: "Jonathan T. Looney" Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 17:53:49 -0000 On Sat, Apr 21, 2018 at 10:05 AM, Jonathan T. Looney 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, Conrad