From owner-svn-src-head@freebsd.org Sat Apr 21 20:33:36 2018 Return-Path: Delivered-To: svn-src-head@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 6FA9FFA13FE; Sat, 21 Apr 2018 20:33:36 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 C37F66CA2E; Sat, 21 Apr 2018 20:33:35 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: by mail-wr0-x236.google.com with SMTP id w3-v6so31123758wrg.2; Sat, 21 Apr 2018 13:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GIiSBvhBpP8Sg0eFCbK7058qGvK+RzUmcW2rlTQI/s0=; b=QOlVozQ2ZIJULndDbU28+ELCB51EFlDIIFVpxP9aRizD88tfo+UFQoGPToLzfCpZvp F+0KIWk/+oBRmZ/TLWF7inN9AhoOfX6tDP0oSCR3S17zcNFMRIax/6wPd9h0myDm8XS1 dEw9UxLP0oyHH6BOeYsp5D9w87N4LCwWhzAIafNqcdFXp882I1fpof5ziowJ8IjbcFAY ZBBMNQCl8JotabvA8qOAAtB7d41vA/H1DxZrBYgTB4STqNdN9jGFDEWBjTpTr9pN5MSw e+FPHfhzq6+xHaWdjb1NSyk1ds14bkSHSJt0fzInZTN5MPRCDl6pYR2tq62d1fyLuCfS eNOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GIiSBvhBpP8Sg0eFCbK7058qGvK+RzUmcW2rlTQI/s0=; b=VSyY0ldNMx7pwDof/NE31WrglaOwvq0DCfgWkq0zbyaeMxgptOd2+On/JqVH+f8Y6s ELmEnTSEreNRB+DqJhO4k8SVFm3qbProR//gV299b6Wf3fFXgFZUKqhXKRewRIRYeQsF bjWSg8vNMCITh/4fcvoEgqXaoH9QtnyPHZbOnghdct45i8c7ld4Z45mwtu0S/ew/rjC1 O+x+yxH/e3B3tDaZ6KWHyqslBCtT0VYV27OXCcLnyuVxT+/9vNaHQ9WJ2CTv061FsgZO kQFSkdUSIxHrvpeQlQ6x3VMsfbgVMNm1xwj+ycAzwHm2I5nI91R2B+LytDjGdWNdE5kG MC0w== X-Gm-Message-State: ALQs6tBPJ0FCyLQbvUn8QVzfPWplNZzvVvFst4AD8fFVZVLxzovoSn+Y PXuADWB01xeSEa74ZDOfRLl1fHrmAXxMUMVPcd/uGGnt X-Google-Smtp-Source: AIpwx49UdZjJEZAFsq5orZ2Mja+s6d29EIlvQlrGqD06DrFguK5wKkSSM0q54IC1WkLUzZLSoCUDw5NB1ZVxlIUvRZ4= X-Received: by 10.28.112.3 with SMTP id l3mr5504289wmc.90.1524342814084; Sat, 21 Apr 2018 13:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.199.203 with HTTP; Sat, 21 Apr 2018 13:33:33 -0700 (PDT) In-Reply-To: References: <201804211705.w3LH50Dk056339@repo.freebsd.org> From: Jonathan Looney Date: Sat, 21 Apr 2018 16:33:33 -0400 Message-ID: Subject: Re: svn commit: r332860 - head/sys/kern To: cem@freebsd.org Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 20:33:36 -0000 On Sat, Apr 21, 2018 at 1:53 PM, Conrad Meyer wrote: > > I don't think this should be enabled by default. Can we leave it > disabled by default and let consumers opt-in? I'm willing to change the default if there's a good reason or consensus for that. However, it is not obvious to me that the default is actually wrong. I think its important that we remember where we are when we hit this code. By the time we hit this code, we've already panic'd (whether due to a "true" panic or a violated assertion). At this point, the system is already in an unknown/unexpected state and we want to preserve our ability to troubleshoot and/or recover. (And, since we're running a system with INVARIANTS, presumably the ability to troubleshoot is important.) We may well violate a second assertion simply because the system is in an unknown/unexpected state. Once we do that, the question is whether we should try to preserve the ability to troubleshoot, or should give up and reset the system. All too often, my ability to debug assertion violations is hindered because the system trips over yet another assertion while dumping the core. If we skip the assertion, nothing bad happens. (The post-panic debugging code already needs to deal with systems that are inconsistent, and it does a pretty good job at it.) On the other hand, I really am not sure what you are worried might happen if we skip checking assertions after we've already panic'd. As far as I can tell, the likely worst case is that we hit a true panic of some kind. In that case, we're no worse off than before. I think the one obvious exception is when we're purposely trying to validate the post-panic debugging code. In that case, you can change the sysctl/tunable to enable troubleshooting. I would honestly appreciate someone explaining the dangers in disabling a response to assertion violations after we've already panic'd and are simply trying to troubleshoot, because they are not obvious to me. But, I could simply be missing them. Jonathan