From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751964AbdJYEWa (ORCPT ); Wed, 25 Oct 2017 00:22:30 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:43256 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751895AbdJYEW1 (ORCPT ); Wed, 25 Oct 2017 00:22:27 -0400 Date: Wed, 25 Oct 2017 13:22:22 +0900 (KST) Message-Id: <20171025.132222.1438740282932861791.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: garsilva@embeddedor.com, steffen.klassert@secunet.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: xfrm_user: use BUG_ON instead of if condition followed by BUG From: David Miller In-Reply-To: <20171025040541.GA1999@gondor.apana.org.au> References: <20171024035320.GA29795@gondor.apana.org.au> <20171024.174842.272234711073180328.davem@davemloft.net> <20171025040541.GA1999@gondor.apana.org.au> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 24 Oct 2017 21:22:26 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Herbert Xu Date: Wed, 25 Oct 2017 12:05:41 +0800 > On Tue, Oct 24, 2017 at 05:48:42PM +0900, David Miller wrote: >> >> This discussion has happened before. >> >> But I'll explain the conclusion here for your benefit. >> >> BUG_ON() is a statement and everything inside of it will >> always execute. >> >> BUG_ON() is always preferred because it allows arch >> specific code to pass the conditional result properly >> into inline asm and builtins for optimal code generation. > > This is a good point. However, while a little bit more verbose you > can still achieve the same assembly-level result by something like > > int err; > > err = ; > BUG_ON(err); > > Having real code in BUG_ON may pose problems to people reading the > code because some of us tend to ignore code in BUG_ON and similar > macros such as BUILD_BUG_ON. I agree that this makes the code easier to read and audit.