Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp226467imm; Thu, 20 Sep 2018 22:23:56 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb9uGJoSVEVTiLkGi0fEig/BKrowLeeNs4M7X/RyobtCoG/4L3gAqQIWuJUoUv1Waa/PfOD X-Received: by 2002:a17:902:848d:: with SMTP id c13-v6mr36403138plo.194.1537507436072; Thu, 20 Sep 2018 22:23:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537507436; cv=none; d=google.com; s=arc-20160816; b=IpR7LOPWWRkNZndfRUGhQE9cDoFMhKPI0LSpDrF1EfxKIGltWXa4Rse9EcFibrU9K/ 9Vl5c6uRHdHZJURuPPy1wUuruZZ8J+8QQSzoB9Caiovw3mzPbX6O0tye5R52q1KPJN3b CHh7oS9q803i1EMEIifpVdNfvgYS/vcZtf7dzNGSbWcmxsl/CvCAi7iDnoJeB+NsanjL 6M4WWjFw6jO1UuNKdabBQRiKAvIC2UOsDREiemE+nxQTu1ebeSyENMmF6iPJ7nze77Iv 9aPaw6eOFynjnO3O0b+ZGei90Ce0O20tL1tgeGT3DFRYlwxZj1g2Ecq5yOYoRhxxJi4+ 8qJA== 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:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id; bh=dfhBCtfsHo3OyLXp22xQLOHSNCvxLiagcu6M3JBDBWA=; b=JZK6TN4XiDDUfOUUzJlGpiyKJINmRMpeiHsPOvvJqHCp5uVzOntJNcJZdZDTMAcll9 7HdIAPiJRUCMvzYkVMLLFdjMQ2lzmVjJQQq7hkFhC7a0Aj3kGa1rKReHCkkAgrhFN3R6 Q5SMv95PpWijDcJKJv1wFkzkYMQBm91RNAL9lj/T71CUEbHFvPEuWiJlCzxshLvi/EfV LuVBWK2Jlde8WRwikcDKBQeYlFYdlTNBlz5ewz2qWDv1RDeWnSiHIaSMqKdCSf9TzAeq wYM7tFrdoZzrAW33yYh/7D5oa+33k5QfgYNwJskHxPG/GSksoPq06VYlqa3rt1JYrI2X qMCw== 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 y26-v6si25544936pfn.111.2018.09.20.22.23.40; Thu, 20 Sep 2018 22:23:56 -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 S2389185AbeIULJO (ORCPT + 99 others); Fri, 21 Sep 2018 07:09:14 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:13091 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725898AbeIULJO (ORCPT ); Fri, 21 Sep 2018 07:09:14 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 09A8652E081AE; Fri, 21 Sep 2018 13:22:02 +0800 (CST) Received: from [127.0.0.1] (10.177.29.68) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.399.0; Fri, 21 Sep 2018 13:22:00 +0800 Message-ID: <5BA47FF7.8090906@huawei.com> Date: Fri, 21 Sep 2018 13:21:59 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jakub Kicinski CC: , , , , Subject: Re: [PATCH] net: netronome: remove redundant continue References: <1537430541-37817-1-git-send-email-zhongjiang@huawei.com> <20180920093857.6227710f@cakuba.netronome.com> In-Reply-To: <20180920093857.6227710f@cakuba.netronome.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.68] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/9/21 0:38, Jakub Kicinski wrote: > On Thu, 20 Sep 2018 16:02:21 +0800, zhong jiang wrote: >> The continue will not truely skip any code. hence it is safe to >> remove it. >> >> Signed-off-by: zhong jiang > I think this came up during review at some point. I still prefer to > keep the continue. The body of the loop performs initialization of > objects, if an object is removed we shouldn't carry on with the body. > It's easy to miss that the object got freed otherwise, there is no > error being set and no warning printed... IMO, we should bring it back when the case truely occur you have said. At present. We should not take too much into account. Maybe it will not occur. Thanks, zhong jiang >> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c >> index 0b1ac9c..50d7b58 100644 >> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c >> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c >> @@ -230,10 +230,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf) >> ctrl_bar += NFP_PF_CSR_SLICE_SIZE; >> >> /* Kill the vNIC if app init marked it as invalid */ >> - if (nn->port && nn->port->type == NFP_PORT_INVALID) { >> + if (nn->port && nn->port->type == NFP_PORT_INVALID) >> nfp_net_pf_free_vnic(pf, nn); >> - continue; >> - } >> } >> >> if (list_empty(&pf->vnics)) > > . >