Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7137310yba; Thu, 2 May 2019 05:03:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqzhws6NNzpcyeBvVN9rMKv2TzoA6c82HjQg7HFbYsiY7l5Xze7hSywLagP+RPq3fgXSFQk5 X-Received: by 2002:a17:902:b617:: with SMTP id b23mr3191047pls.73.1556798610817; Thu, 02 May 2019 05:03:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556798610; cv=none; d=google.com; s=arc-20160816; b=fw4q09t6C18H8UoSUTiAKthPTTOBwdzmZ29rS7A6xTrq9jdQwJk0xnsSkV13CthPEv dZNA2A7LaygU5M022AH2z7qogFs7aRzO3tSPYCmqrRt0Tn15x053ya9WVec7e0fX5D0Z vkLbPQtzJcLUiXgSZTKDmTmZtokP6siQ1Y93egD48S6BlxHwy+hFjB5YGTch9fts+ngP QEOd9xnZ5J7cAyo23PkecvcCZoLrwG5emmej3jO5RLD8l88zAtU2XNfmUSnovJtG2JQo c1u5pn6+2TzFasdO9d8B0NRNqv0MfTT6tzSRMw9KXR/1hQO8k5HiBWnvkCja82SmmOxd IxkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=WWk2x9TLc6uvQBjVfaO0Dxg+YNeC2idgZDun5Tbnnmo=; b=uZyVPjIh4xSRnZejiFLzQ80Xn8FHt/pFVCenG5uqfR7A99XwTLubvgwxSIAvhu1DJj +L0q0XOuGhGJYPUqTRVBoFM1P7JSnAcSgunXfWTkGwNKh3ZUsLyZAE7HwuXui0JKC3Tc 15PVfvHAzvCuF08Mjj3ClVso46zIezT77weIeyWQcGU5bodcL+/9KtEgTeb1UE0DFDvC g9v8a9hKlePA/E9ghImyRSVPAqyldP4k6+vkgPQ8Vf74mfNJr3b3DYQqhj6z2DwIxEqY XhEHNQ+EVAnhjKvgFi11UBcmrBiP9Vj5wbeXXAv8/8LVpLMKuFi2MFea0T7WCx96RFmJ dtEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9si8255689pgh.391.2019.05.02.05.03.13; Thu, 02 May 2019 05:03:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726447AbfEBMCJ (ORCPT + 99 others); Thu, 2 May 2019 08:02:09 -0400 Received: from ozlabs.org ([203.11.71.1]:45015 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbfEBMCJ (ORCPT ); Thu, 2 May 2019 08:02:09 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 44vv5B0821z9s9N; Thu, 2 May 2019 22:02:05 +1000 (AEST) From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , aneesh.kumar@linux.ibm.com Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 01/17] powerpc/mm: Don't BUG() in hugepd_page() In-Reply-To: References: Date: Thu, 02 May 2019 22:02:05 +1000 Message-ID: <87o94lxdxe.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > Use VM_BUG_ON() instead of BUG_ON(), as those BUG_ON() > are not there to catch runtime errors but to catch errors > during development cycle only. I've dropped this one and the next, because I don't like VM_BUG_ON(). Why not? Because it's contradictory. It's a condition that's so important that we should BUG, but only if the kernel has been built specially for debugging. I don't really buy the development cycle distinction, it's not like we have a rigorous test suite that we run and then we declare everything's gold and ship a product. We often don't find bugs until they're hit in the wild. For example the recent corruption Joel discovered with STRICT_KERNEL_RWX could have been caught by a BUG_ON() to check we weren't patching kernel text in radix__change_memory_range(), but he wouldn't have been using CONFIG_DEBUG_VM. (See 8adddf349fda) I know Aneesh disagrees with me on this, so maybe you two can convince me otherwise. cheers > diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h > index 8d40565ad0c3..7f1867e428c0 100644 > --- a/arch/powerpc/include/asm/hugetlb.h > +++ b/arch/powerpc/include/asm/hugetlb.h > @@ -14,7 +14,7 @@ > */ > static inline pte_t *hugepd_page(hugepd_t hpd) > { > - BUG_ON(!hugepd_ok(hpd)); > + VM_BUG_ON(!hugepd_ok(hpd)); > /* > * We have only four bits to encode, MMU page size > */ > @@ -42,7 +42,7 @@ static inline void flush_hugetlb_page(struct vm_area_struct *vma, > > static inline pte_t *hugepd_page(hugepd_t hpd) > { > - BUG_ON(!hugepd_ok(hpd)); > + VM_BUG_ON(!hugepd_ok(hpd)); > #ifdef CONFIG_PPC_8xx > return (pte_t *)__va(hpd_val(hpd) & ~HUGEPD_SHIFT_MASK); > #else > -- > 2.13.3