From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24D41C433EF for ; Fri, 24 Sep 2021 01:40:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0908460EDF for ; Fri, 24 Sep 2021 01:40:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243780AbhIXBlc (ORCPT ); Thu, 23 Sep 2021 21:41:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:58326 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243687AbhIXBlb (ORCPT ); Thu, 23 Sep 2021 21:41:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D219261211; Fri, 24 Sep 2021 01:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632447598; bh=wS1vTfdanTeolFqG6+BwOprrXt9fA9ocCesCstsfaz8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MZOniup1k2WBdEvqe0zUTShI/0nU7LP+azNYTosMus0zFLH7Fq6fcCZ8wnsf79Pa+ wBmx2Pqc2RaBXMCWDhaKXskn4qMGz2TQTy295735OXxCfQ0t7vWXmNiFkwUpBzakar AXEiT86ORr+UbhUTdPLHbhy9EYHzjIrOEY0DQgXzoLZ49ngS3mdqy6hv65XMSTmO8B DWHRAUGrr8hHPHGug+/N/Cfpdyc8vv+GKhFNYUR2hkMbP4IZXgS4DGw0O+xcQP52j+ +DImiTrG6bdT1W3TUJWEQr2WOfxBqlbt1unriLklN5+HLo5ewI9oCWBSS3P8pS9H16 PmZZpnYCCtf2Q== Date: Thu, 23 Sep 2021 18:39:56 -0700 From: Jakub Kicinski To: Leon Romanovsky Cc: Edwin Peer , "David S . Miller" , Alexander Lobakin , Anirudh Venkataramanan , Ariel Elior , GR-everest-linux-l2@marvell.com, GR-QLogic-Storage-Upstream@marvell.com, Igor Russkikh , intel-wired-lan@lists.osuosl.org, "James E.J. Bottomley" , Javed Hasan , Jeff Kirsher , Jesse Brandeburg , Jiri Pirko , Linux Kernel Mailing List , linux-scsi@vger.kernel.org, "Martin K. Petersen" , Michael Chan , Michal Kalderon , netdev , Sathya Perla , Saurav Kashyap , Tony Nguyen , Vasundhara Volam Subject: Re: [PATCH net-next 1/6] bnxt_en: Check devlink allocation and registration status Message-ID: <20210923183956.506bfde2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 24 Sep 2021 02:11:19 +0300 Leon Romanovsky wrote: > > > @@ -835,9 +837,6 @@ void bnxt_dl_unregister(struct bnxt *bp) > > > { > > > struct devlink *dl = bp->dl; > > > > > > - if (!dl) > > > - return; > > > - > > > > minor nit: There's obviously nothing incorrect about doing this (and > > adding the additional error label in the cleanup code above), but bnxt > > has generally adopted a style of having cleanup functions being > > idempotent. It generally makes error handling simpler and less error > > prone. > > I would argue that opposite is true. Such "impossible" checks hide unwind > flow errors, missing releases e.t.c. +1, fwiw From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Date: Thu, 23 Sep 2021 18:39:56 -0700 Subject: [Intel-wired-lan] [PATCH net-next 1/6] bnxt_en: Check devlink allocation and registration status In-Reply-To: References: Message-ID: <20210923183956.506bfde2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Fri, 24 Sep 2021 02:11:19 +0300 Leon Romanovsky wrote: > > > @@ -835,9 +837,6 @@ void bnxt_dl_unregister(struct bnxt *bp) > > > { > > > struct devlink *dl = bp->dl; > > > > > > - if (!dl) > > > - return; > > > - > > > > minor nit: There's obviously nothing incorrect about doing this (and > > adding the additional error label in the cleanup code above), but bnxt > > has generally adopted a style of having cleanup functions being > > idempotent. It generally makes error handling simpler and less error > > prone. > > I would argue that opposite is true. Such "impossible" checks hide unwind > flow errors, missing releases e.t.c. +1, fwiw