From owner-freebsd-arch@freebsd.org Wed May 11 16:30:54 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 290A5B37B78 for ; Wed, 11 May 2016 16:30:54 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com [209.85.218.66]) (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 EDB921969 for ; Wed, 11 May 2016 16:30:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi0-f66.google.com with SMTP id w198so7954662oiw.2 for ; Wed, 11 May 2016 09:30:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to; bh=roD8tkemRcnvYjcMIhSjeRSsQq1EHVQdP78PawIaQpQ=; b=WdX/T8pmMhWsz89BidAiJIgWDx6EdEp6u/WZEu8iTf/WC/uawkJDckfFrhFEuLVkZ+ F7Adhgco+72RvRupINyxvbYXSNr1VcyXq+r07//kH0FmwV31vs4rUWtIDXSLTTU5qP9H V6otbxqkJDc2lyvidrBK4+wiqKxP6bTfs8rE23yjvDURMZg9C/+8LFXfgAdoOcnmcA7S bnSiKWu43Dz+feHP3ZRgWBZGAjT65ufOcRl8+wcUR0GfyQqLPeHCdr7L0BJnjA1QDCyM 417M610eEt7iZRkQUePe03h9zmD65b2hdcjNx+8vzf5VrI5VAI3kOjuHKpe2pyLpmhkD vpyA== X-Gm-Message-State: AOPr4FX3kpg5rZ3UWN7E8UkUalbmq7HnxQsOGVXbMlHxfIVTXRlzO2qzw/mh6lvp65o4Rw== X-Received: by 10.202.220.87 with SMTP id t84mr2319242oig.57.1462984247304; Wed, 11 May 2016 09:30:47 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id ry2sm2319694oeb.4.2016.05.11.09.30.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 May 2016 09:30:47 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id x201so76532701oif.3 for ; Wed, 11 May 2016 09:30:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.215.86 with SMTP id o83mr2349462oig.55.1462984246638; Wed, 11 May 2016 09:30:46 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.157.19.20 with HTTP; Wed, 11 May 2016 09:30:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 May 2016 09:30:46 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASSERT: always assert; KWARN From: Conrad Meyer To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:30:54 -0000 On Wed, May 11, 2016 at 9:04 AM, Alfred Perlstein wrote: > On 5/10/16 6:24 PM, Conrad Meyer wrote: > >> Thoughts or objections? Does anyone like the ability to opt out of >> invariants asserts? > > > Yes. > > During my time at iXsystems we used this facility several times to get a log > from a customer site with a number of "kasserts". > > The reason we did this was multiple reasons: > 1) We needed to ship a kernel with asserts enabled. > 2) When we did, the first assert hit was: > a) In an unrelated module and not relevant. > b) Not enough information came back from just the first assert. > 3) We found it more useful to get multiple errors back from a customer in > one trip rather than one fix at a time. Unfortunately one fix at a time > would have had us lose the customer. > > The KASSERT/assert system is very, very, very useful. However if you are at > a last resort sending a debug kernel (with Kassert enabled) and do not get > enough information back then you will lose that customer. > > I understand that a few vocal folks are upset, like seriously, seriously > upset, however at the time this was the only way we could effectively debug > a customer problem and my hope was that others could make use of it as well. > > Linux has had a similar functionality for many years. In Linux there is the > kernel "oops()" which does nearly the same thing. > > Initially I mocked Linux's "oops" for being silly and "wrong", using the > exact same reasons that many have used to dislike "kassert_warn". However > once I was responsible for an extremely pissed off customer who was paying > us quite a sum of money AND I was not getting enough information back, I > changed my mind. > > https://en.wikipedia.org/wiki/Linux_kernel_oops Hi, Here's my follow-up from the Phabricator review. (Alfred, you've already seen it. But, for everyone else:) Here's another proposal: Add a mode between INVARIANTS off and INVARIANTS on. Call it INVARIANTS_OPTIONAL. * In !INVARIANTS mode, you don't have KASSERTs at all (like today). * In INVARIANTS && INVARIANTS_OPTIONAL mode, you get the all the print-and-continue KASSERT knobs you have today. (So, same default of panicing, but optionally they can be disabled and turned into logs.) * In INVARIANTS && !INVARIANTS_OPTIONAL mode, KASSERT always panics. I would suggest GENERIC move from the current mode, effectively INVARIANTS_OPTIONAL, to !INVARIANTS_OPTIONAL. But if you want to ship a kernel with pass-through assertions enabled, you can still do that by enabling INVARIANTS_OPTIONAL. This gives the expected KASSERT behavior for Coverity modeling, and still enables the KASSERT-lite use case. (It would just be kicked out of GENERIC.) Adrian, would that meet your needs? Thanks, Conrad