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=-17.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 91065C4332F for ; Thu, 23 Sep 2021 23:11:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A158611B0 for ; Thu, 23 Sep 2021 23:11:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243565AbhIWXM7 (ORCPT ); Thu, 23 Sep 2021 19:12:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:46392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243533AbhIWXM6 (ORCPT ); Thu, 23 Sep 2021 19:12:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BBA3D61107; Thu, 23 Sep 2021 23:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632438683; bh=ILJ6ftNnE9k3HLjd3767aM80d5dSXwBb9STyViQHsTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d6xb0sBmcLCsSN4o8Nmf9iBZmY6iH5GTHlUTZ4njs2oiGZTh3bnipzbuFqBILzhNF 5px5K9H0CcDO51xqA9JT5vbfYRvb9wt8A5YJkii6rglY3yLCjLi3U1TJCSOg6MH0ua eJZMmO7dG0QNdxwpNvFnPdz7dCOh1N4ATR7X0vZuwImk2U5Q4n4mPV9UU118v2M8t+ eTKCfSnGGoRgXKY1yZ9mLmZFBh6XZmK0VDZwqFmrBtco2c20AVkDiryk+MiBSjAc7B y2f/O2BPpkQuZ0h5UBgPN+RYTGDMXjGds1n4mYmeT1rGszU4aOEnTuVOV5KJjynLXJ zEIphBay1IBcg== Date: Fri, 24 Sep 2021 02:11:19 +0300 From: Leon Romanovsky To: Edwin Peer Cc: "David S . Miller" , Jakub Kicinski , 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: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 23, 2021 at 02:11:40PM -0700, Edwin Peer wrote: > On Thu, Sep 23, 2021 at 11:13 AM Leon Romanovsky wrote: > > > > From: Leon Romanovsky > > > > devlink is a software interface that doesn't depend on any hardware > > capabilities. The failure in SW means memory issues, wrong parameters, > > programmer error e.t.c. > > > > Like any other such interface in the kernel, the returned status of > > devlink APIs should be checked and propagated further and not ignored. > > > > Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors") > > Signed-off-by: Leon Romanovsky > > --- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 ++++- > > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 13 ++++++------- > > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 13 ------------- > > 3 files changed, 10 insertions(+), 21 deletions(-) <...> > > @@ -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. <...> > > > > Reviewed-by: Edwin Peer Thanks for the review. > > Regards, > Edwin Peer From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leon Romanovsky Date: Fri, 24 Sep 2021 02:11:19 +0300 Subject: [Intel-wired-lan] [PATCH net-next 1/6] bnxt_en: Check devlink allocation and registration status In-Reply-To: References: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Thu, Sep 23, 2021 at 02:11:40PM -0700, Edwin Peer wrote: > On Thu, Sep 23, 2021 at 11:13 AM Leon Romanovsky wrote: > > > > From: Leon Romanovsky > > > > devlink is a software interface that doesn't depend on any hardware > > capabilities. The failure in SW means memory issues, wrong parameters, > > programmer error e.t.c. > > > > Like any other such interface in the kernel, the returned status of > > devlink APIs should be checked and propagated further and not ignored. > > > > Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors") > > Signed-off-by: Leon Romanovsky > > --- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 ++++- > > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 13 ++++++------- > > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 13 ------------- > > 3 files changed, 10 insertions(+), 21 deletions(-) <...> > > @@ -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. <...> > > > > Reviewed-by: Edwin Peer Thanks for the review. > > Regards, > Edwin Peer