Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6180476rwd; Mon, 19 Jun 2023 03:41:46 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4dKdWuqETc25JJ2SeVIt8kieHaeMUofVs1petKjfP4cKIeliaiuNkCJzEqgAPzdgLL/eD+ X-Received: by 2002:a17:902:e5cd:b0:1b5:79b:8b14 with SMTP id u13-20020a170902e5cd00b001b5079b8b14mr12759775plf.26.1687171305796; Mon, 19 Jun 2023 03:41:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687171305; cv=none; d=google.com; s=arc-20160816; b=jOq5igrYNylAYtW4U3AfiG/Gi7cH7a3z47f6UYgiGZQhe6wkVpQ6kOsF41qaK20r52 cqe8+tV/oT4FmMOQvVgwHZckiqCmlakpON4fkSD2ocyNuH1KwjkBxVJs2Y5ScEc5vQJ4 HbJnxUuqBF6ApeaiwTARocq8sRIGI0TIYEOxbZ3QOyqXLIuD2delgx5HzD77DFkyL3vZ rV7kVEbqELbn41AEfd26lWpWzsEPZ1uf92xkxdMJl5haQ/TSsZcP3MMUkMVQsPinAxtz Rk0Y+KhUkIWJiMaTaEmi7D3n45gsrJ9FtDJAiad0x7Ax5UBvUKtMJl4CYyTuFL8EPiVP vaog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=TZCfuT5d5MExtAKWGaSRen9Gk/+uWOoboeQsmItklLA=; b=1K8JAfRGvWwG/vr6XqJkBGFPprsEp9cFu0WXnPJAiUMNYzcUPjFSeMca1KhTeiizeQ j7gkHDT0uWjnx4K9AEeRo9EOedjcEZ6Ymm0uabjXROQ591DckCFM8i/fg2san7OL+2ww LzV2GhYikeF77CP9kwDeIVZvRWRTVsUnP1nH+/yNVKDuDeg6uaNLHd+2D25XdTXBtfl5 +u1jlvCb/QJcOS+bfyCzfpPg/0+rbMwxioy0de1g2J8bDOOfWtFTQPxAxoihqjRli26p +volKPlC6dVTPK/UYbfwNc8uPf5O/Aqk6XzEibRMnZXemi1GCD70+izUuT5/DF0wt+Wo /Qcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u6-20020a170902e80600b001adb857fc79si3056760plg.105.2023.06.19.03.41.33; Mon, 19 Jun 2023 03:41:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231769AbjFSKfZ (ORCPT + 99 others); Mon, 19 Jun 2023 06:35:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232096AbjFSKfE (ORCPT ); Mon, 19 Jun 2023 06:35:04 -0400 Received: from mx3.molgen.mpg.de (mx3.molgen.mpg.de [141.14.17.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17FB310D0; Mon, 19 Jun 2023 03:34:54 -0700 (PDT) Received: from [141.14.220.45] (g45.guest.molgen.mpg.de [141.14.220.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 79B7061E5FE04; Mon, 19 Jun 2023 12:34:08 +0200 (CEST) Message-ID: Date: Mon, 19 Jun 2023 12:34:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [Intel-wired-lan] [PATCH net] ice: ice_vsi_release cleanup Content-Language: en-US To: Petr Oros Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com, linux-kernel@vger.kernel.org, edumazet@google.com, anthony.l.nguyen@intel.com, kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net References: <20230619084948.360128-1-poros@redhat.com> From: Paul Menzel In-Reply-To: <20230619084948.360128-1-poros@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Petr, Thank you for your patch. Am 19.06.23 um 10:49 schrieb Petr Oros: > Since commit 6624e780a577fc ("ice: split ice_vsi_setup into smaller > functions") ice_vsi_release does things twice. There is unregister > netdev which is unregistered in ice_deinit_eth also. > > It also unregisters the devlink_port twice which is also unregistered > in ice_deinit_eth(). This double deregistration is hidden because > devl_port_unregister ignores the return value of xa_erase. > > [ 68.642167] Call Trace: > [ 68.650385] ice_devlink_destroy_pf_port+0xe/0x20 [ice] > [ 68.655656] ice_vsi_release+0x445/0x690 [ice] > [ 68.660147] ice_deinit+0x99/0x280 [ice] > [ 68.664117] ice_remove+0x1b6/0x5c0 [ice] > > [ 171.103841] Call Trace: > [ 171.109607] ice_devlink_destroy_pf_port+0xf/0x20 [ice] > [ 171.114841] ice_remove+0x158/0x270 [ice] > [ 171.118854] pci_device_remove+0x3b/0xc0 > [ 171.122779] device_release_driver_internal+0xc7/0x170 > [ 171.127912] driver_detach+0x54/0x8c > [ 171.131491] bus_remove_driver+0x77/0xd1 > [ 171.135406] pci_unregister_driver+0x2d/0xb0 > [ 171.139670] ice_module_exit+0xc/0x55f [ice] It’d be more specific in the commit message summary/title, and use imperative mood. Maybe: ice: Unregister netdev and devlink_port only once Kind regards, Paul > Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") > Signed-off-by: Petr Oros > --- > drivers/net/ethernet/intel/ice/ice_lib.c | 27 ------------------------ > 1 file changed, 27 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c > index 11ae0e41f518a1..284a1f0bfdb545 100644 > --- a/drivers/net/ethernet/intel/ice/ice_lib.c > +++ b/drivers/net/ethernet/intel/ice/ice_lib.c > @@ -3272,39 +3272,12 @@ int ice_vsi_release(struct ice_vsi *vsi) > return -ENODEV; > pf = vsi->back; > > - /* do not unregister while driver is in the reset recovery pending > - * state. Since reset/rebuild happens through PF service task workqueue, > - * it's not a good idea to unregister netdev that is associated to the > - * PF that is running the work queue items currently. This is done to > - * avoid check_flush_dependency() warning on this wq > - */ > - if (vsi->netdev && !ice_is_reset_in_progress(pf->state) && > - (test_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state))) { > - unregister_netdev(vsi->netdev); > - clear_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state); > - } > - > - if (vsi->type == ICE_VSI_PF) > - ice_devlink_destroy_pf_port(pf); > - > if (test_bit(ICE_FLAG_RSS_ENA, pf->flags)) > ice_rss_clean(vsi); > > ice_vsi_close(vsi); > ice_vsi_decfg(vsi); > > - if (vsi->netdev) { > - if (test_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state)) { > - unregister_netdev(vsi->netdev); > - clear_bit(ICE_VSI_NETDEV_REGISTERED, vsi->state); > - } > - if (test_bit(ICE_VSI_NETDEV_ALLOCD, vsi->state)) { > - free_netdev(vsi->netdev); > - vsi->netdev = NULL; > - clear_bit(ICE_VSI_NETDEV_ALLOCD, vsi->state); > - } > - } > - > /* retain SW VSI data structure since it is needed to unregister and > * free VSI netdev when PF is not in reset recovery pending state,\ > * for ex: during rmmod.