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 Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 574EFFF8868 for ; Mon, 27 Apr 2026 16:52:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 0E21A4065D; Mon, 27 Apr 2026 16:52:28 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id UvRKUZheb5c7; Mon, 27 Apr 2026 16:52:26 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A243540660 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1777308746; bh=2fu+xvwb8ZJWiTON3ATIujkArv76wZ5f5nn16cPbd0g=; h=From:To:Cc:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=k2rjzQ6rvkXSrPcxJKMlZADdXzzt2mgSIK+EmRefpLwiPR18JfAv/YYp6q0fb9Vn/ ZF3pvBMPQword77E5n2LRoV3XtJ+hsC7rn1lU5datqP2vmP2RNLKFqDNvjpXpJ/srU Fp9XrEMh6mPNUyAkZ8O2z4lmGUEl1kpErMzuKLVU5sdf+o2MlLeo8FeQz0U9A14EAP nGQXFUZSPA5t9nMsnHIVkKfPvxwoMDUC7nO6dQa7fBBQsQwrXqBcveWX3+fYmwHn0L rQEAm2a3w7zFEM3+p6PHu/reix0baLUlddwcSYsewSfF5HO4/fdXLo1WLY+cXIYm8C WVIMRDzrNbtRw== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp4.osuosl.org (Postfix) with ESMTP id A243540660; Mon, 27 Apr 2026 16:52:26 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists1.osuosl.org (Postfix) with ESMTP id B35332DF for ; Mon, 27 Apr 2026 16:52:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A54CD4009E for ; Mon, 27 Apr 2026 16:52:25 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id Ezj7XO6UEli5 for ; Mon, 27 Apr 2026 16:52:25 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp2.osuosl.org DB0984008A DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DB0984008A Received: from sea.source.kernel.org (sea.source.kernel.org [IPv6:2600:3c0a:e001:78e:0:1991:8:25]) by smtp2.osuosl.org (Postfix) with ESMTPS id DB0984008A for ; Mon, 27 Apr 2026 16:52:24 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 68FA64182D; Mon, 27 Apr 2026 16:52:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D34AAC19425; Mon, 27 Apr 2026 16:52:21 +0000 (UTC) From: Simon Horman To: jtornosm@redhat.com Cc: 'Simon Horman' , netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, przemyslaw.kitszel@intel.com, aleksandr.loktionov@intel.com, jacob.e.keller@intel.com, jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Date: Mon, 27 Apr 2026 17:50:45 +0100 Message-ID: <20260427165045.1228721-1-horms@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260423130405.139568-5-jtornosm@redhat.com> References: <20260423130405.139568-5-jtornosm@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777308744; bh=ETP5cbZBx5BXdzQHP8lPfMRyGrQXvV0TD9QSKFc4srE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TMiD9d/gnr+BdZknfY5sngLMZIcEnTQ7MPCD+wG+GIE8sWtujrLosR3Kg76IoB/x4 RmbsYiy7jF4ZMGnnZvFHxVGjPtlXmooPqIjl8V71nI7qS701xa+NaB1oE2fC9SWotQ 1knxWGrtAjoLGfGNDM1vv/1Mtg5L9p7ISN8ZHrzU7T3IJOOJbEwHwS9Fy7Nr7UwKH+ JFNbLDea0DVJLVqZyZKHYMStfzQBVtoZpIvUv4dwLwepdzy5R89xrykQYPHZZua0Nu tskggTbfZ64hOS3Ai4xJypY/TDSf2caO6e3fclKV1/mvW2GDHHaJY5A/VXtMyYowHB eZs1kFyofFi4Q== X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=TMiD9d/g Subject: Re: [Intel-wired-lan] [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" From: 'Simon Horman' This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible. Full review at: https://sashiko.dev --- ice: skip unnecessary VF reset when setting trust This patch attempts to optimize VF trust setting changes by skipping the VF reset when granting trust, and only resetting when revoking trust if MAC LLDP filters are present. It also fixes a race condition by doing the reset before clearing the LLDP filters. > diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c > index 7e00e091756ddc..8686c382404f3f 100644 > --- a/drivers/net/ethernet/intel/ice/ice_sriov.c > +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c [ ... ] > @@ -1399,11 +1427,16 @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool trusted) > > mutex_lock(&vf->cfg_lock); > > - while (!trusted && vf->num_mac_lldp) > - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false); > - > + /* Reset only if revoking trust with MAC LLDP filters */ > + if (!trusted && vf->num_mac_lldp) { > + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY); Does ice_reset_vf() clear vf->num_mac_lldp to 0 when it calls ice_vf_pre_vsi_rebuild() internally? If so, does this make the following while loop dead code, bypassing the ice_vf_update_mac_lldp_num() calls that cleanly decrement the count and trigger ice_vsi_cfg_sw_lldp() to clean up the LLDP software switch rules? > + while (vf->num_mac_lldp) > + ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false); > + } else { > + ice_setup_vf_trust(vf, trusted); > + } If we revoke trust (!trusted) and vf->num_mac_lldp > 0, we enter the if block and skip the else block containing ice_setup_vf_trust(). When ice_reset_vf() rebuilds the VSI, vf->trusted is still true. Will the rebuild process use this true value to set the ICE_VIRTCHNL_VF_CAP_PRIVILEGE bit in vf->vf_caps? Since ice_setup_vf_trust() is skipped, does this fail to explicitly clear the privilege capability bit? Could a malicious VM add a MAC LLDP filter before trust is revoked to ensure num_mac_lldp > 0, thereby retaining its privileges? Furthermore, when revoking trust and vf->num_mac_lldp == 0, we take the else branch and skip ice_reset_vf(). Trusted VFs are permitted to allocate more than ICE_MAX_MACADDR_PER_VF or ICE_MAX_VLAN_PER_VF limits. Previously, the unconditional ice_reset_vf() would tear down the VSI and purge these extra non-default filters. Without the reset, is there any logic in ice_setup_vf_trust() to prune the extra MAC and VLAN filters that were added while the VF was trusted? Will skipping the reset allow an untrusted VF to retain excessive hardware filters indefinitely and potentially exhaust PF resources? > vf->trusted = trusted; > - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY); > + > dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n", > vf_id, trusted ? "" : "un"); >