Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4509923imm; Tue, 11 Sep 2018 13:03:40 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda1pOn9HjDvubQszzt0PoC+OirhqLDFBZpB/dNBSMn3vNQFoZScsNdFeLaLeK/QLEahhVRO X-Received: by 2002:a17:902:a9ca:: with SMTP id b10-v6mr28442279plr.198.1536696220638; Tue, 11 Sep 2018 13:03:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536696220; cv=none; d=google.com; s=arc-20160816; b=HLENAObZPRopRdLxUjJ+mKf9nYuv2DDLL4uosDZyybpdwpiTJ6sX/UWaKbGJgsgf/M cAzDXmEbZMPxoly+sQcAYpl4CUI6iB4VCdXTnUeQuB0pdqeSlt09Caa/cCtUiqIZ9c4X l+QDNJerPMTfe4RdMF4XCZQdBELQ+ABd4rl4EFH0qWNBQMa0hmwdnmNcEidb7lz1G7jL BtdHbLTZKXvV0R3aKrel+wzTQVeGTAdck2PqideoHkXiKTNTO8MH1MJYVGWoys15op/Z I5ilZhDpFyLIts+yQLjvZp8r+zJV88bQXrCP5UaM5PzbH0Hou94E7AHCguJUFwu4xx3B qnwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id; bh=LuCDL+ht+yZ61ooTLQZHbavgTOm4IgZerNJWEQe6pHw=; b=x1dgNUkFVBV+ZDJYz45MSxLI1El9xfkffgfR6mfE2W4LvZFBykFeJo5Cvd+gj77fI7 RJj0zAeOtLBia4s+4XobuqINYnPSHM1PhXesicEl7XWreXDNivf5aTYcszmvM00C7KTF 3avht9cJIbL/GFhUFtaoa/KC2bQtbVdyiupdw+xYTpcc542i0D8jahRxNeYCTa6hLQI0 4nQF3iF2wA0VCCZ2ODRAyEapIB+SnoU50Qg0ScNBsvYbQo+26Vcb8IQm3bBdrZxIeCiG k6G0mifwGJtR5jAY8F8gIGUbtRYWRaWEeyuGGBZBzp/mg+RP9DtjNk+ylz0FFD+7NBqq g97Q== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q17-v6si20657743pgc.464.2018.09.11.13.03.21; Tue, 11 Sep 2018 13:03:40 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727445AbeILBDk (ORCPT + 99 others); Tue, 11 Sep 2018 21:03:40 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:51637 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbeILBDk (ORCPT ); Tue, 11 Sep 2018 21:03:40 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126] helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fzos0-0001fA-25; Tue, 11 Sep 2018 21:02:44 +0100 Message-ID: <1536696163.3024.146.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 47/79] ieee802154: at86rf230: switch from BUG_ON() to WARN_ON() on problem From: Ben Hutchings To: Stefan Schmidt , Sasha Levin Cc: Greg Kroah-Hartman , LKML , stable Date: Tue, 11 Sep 2018 21:02:43 +0100 In-Reply-To: <20180823074922.172707485@linuxfoundation.org> References: <20180823074918.641878835@linuxfoundation.org> <20180823074922.172707485@linuxfoundation.org> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-08-23 at 09:53 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > ------------------ > > From: Stefan Schmidt > > [ Upstream commit 20f330452ad8814f2289a589baf65e21270879a7 ] > > The check is valid but it does not warrant to crash the kernel. A > WARN_ON() is good enough here. > Found by checkpatch. If the BUG/WARN fires, the very next statement is going to cause an oops. So this doesn't fix anything. Either it's OK for a null pointer to be a fatal error, in which case the WARN can be removed, or that shouldn't be a fatal error, in which case the following assignment needs to be conditional. Ben. > Signed-off-by: Stefan Schmidt > Signed-off-by: Sasha Levin > Signed-off-by: Greg Kroah-Hartman > --- >  drivers/net/ieee802154/at86rf230.c |    2 +- >  1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/drivers/net/ieee802154/at86rf230.c > +++ b/drivers/net/ieee802154/at86rf230.c > @@ -932,7 +932,7 @@ at86rf230_xmit(struct ieee802154_hw *hw, >  static int >  at86rf230_ed(struct ieee802154_hw *hw, u8 *level) >  { > - BUG_ON(!level); > + WARN_ON(!level); >   *level = 0xbe; >   return 0; >  } -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom