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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 888B4FF8877 for ; Wed, 29 Apr 2026 10:25:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5FF7061113; Wed, 29 Apr 2026 10:25:24 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id BDChPEP7a7NF; Wed, 29 Apr 2026 10:25:23 +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 smtp3.osuosl.org 8766A61193 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1777458323; bh=wFXSuTbArLWA6KgK84tVAXunsrSDHkBByEg9Ue3Lwfs=; h=From:To:Cc:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=79+kvdQAoQUNCJWLTqmH1o2CynAemkvnt3IUmPMxPQ+Gp04F1yZoSG6NLcDTSbB0Y Dj7JFroJE6erQ70TL1n2nd1lJLjaeOX3k5ZDiAaZRjs7wzQ6MzUTapRBCvSEOo8z4i RfiF9ob5Lhn4BNN54z2PzJxrm77sH2id65Q7PjPIn6YWlyo196giSObHFRl596zc77 d+BK5wHhPoU+Aj/Sa49N37XgYu9i2V+pTdGzrf4QhWQ7g28YQ23V3wennQFOxhZ96/ k5XMXnL8CqnOfSAGOFg6KBVH8IZCXbPCSIB0eunuAj+eJ7lH2EAz1jHqAlGj33zb/3 hhXrA/jem5bzQ== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp3.osuosl.org (Postfix) with ESMTP id 8766A61193; Wed, 29 Apr 2026 10:25:23 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists1.osuosl.org (Postfix) with ESMTP id 6AF5F231 for ; Wed, 29 Apr 2026 10:25:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 5CCAB42031 for ; Wed, 29 Apr 2026 10:25:22 +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 Hzm0IaLUVMnk for ; Wed, 29 Apr 2026 10:25:21 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=jtornosm@redhat.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp2.osuosl.org 50FBB4202D DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 50FBB4202D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp2.osuosl.org (Postfix) with ESMTPS id 50FBB4202D for ; Wed, 29 Apr 2026 10:25:21 +0000 (UTC) Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-133-Jg18yUZpOsORwEPjjFjR5w-1; Wed, 29 Apr 2026 06:25:16 -0400 X-MC-Unique: Jg18yUZpOsORwEPjjFjR5w-1 X-Mimecast-MFC-AGG-ID: Jg18yUZpOsORwEPjjFjR5w_1777458314 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C2C381800366; Wed, 29 Apr 2026 10:25:14 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.32.45]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 421881800446; Wed, 29 Apr 2026 10:25:09 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: netdev@vger.kernel.org Cc: intel-wired-lan@lists.osuosl.org, przemyslaw.kitszel@intel.com, aleksandr.loktionov@intel.com, jacob.e.keller@intel.com, horms@kernel.org, jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Jose Ignacio Tornos Martinez Date: Wed, 29 Apr 2026 12:24:26 +0200 Message-ID: <20260429102426.210750-5-jtornosm@redhat.com> In-Reply-To: <20260429102426.210750-1-jtornosm@redhat.com> References: <20260429102426.210750-1-jtornosm@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-MFC-PROC-ID: h2IKjYliYAMhDoBdBlA20gyZSu1qVZ7wj9aBy105ReA_1777458314 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1777458320; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wFXSuTbArLWA6KgK84tVAXunsrSDHkBByEg9Ue3Lwfs=; b=fGIk0aY7JlyGgocQBwmZHSUx12ova1Wi1sI/V3gXa7VhWoZy0gS92TYyyfmEUlREitOXFy PPisRoSOIAlti3TdvwPwkD2wkeGux+MgycLaTjo69E2i+mIX+W6qVIUueioy2mV04XbrTv W69/luIoXpAEwd39ITVvz2pysHKGyM8= X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com X-Mailman-Original-Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fGIk0aY7 Subject: [Intel-wired-lan] [PATCH net v5 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" Similar to the i40e fix, ice_set_vf_trust() unconditionally calls ice_reset_vf() when the trust setting changes. While the delay is smaller than i40e this reset is still unnecessary in most cases. Additionally, the original code has a race condition: it deletes MAC LLDP filters BEFORE resetting the VF. During this deletion, the VF is still ACTIVE and can add new MAC LLDP filters concurrently, potentially corrupting the filter list. When granting trust, no reset is needed - we can just set the capability flag to allow privileged operations. When revoking trust, we only need to reset (conservative approach) if the VF has actually configured advanced features that require cleanup (MAC LLDP filters, promiscuous mode). For VFs in a clean state, we can safely change the trust setting without the disruptive reset. When we do reset (MAC LLDP case), we fix the race condition by resetting first to clear VF state (which blocks new MAC LLDP filter additions), then delete existing filters safely. During cleanup, vf->trusted remains true so ice_vf_is_lldp_ena() works properly. Only after cleanup do we set vf->trusted = false. When we don't reset, we manually handle capability flag via helper function, eliminating the delay. Fixes: 2296345416b0 ("ice: receive LLDP on trusted VFs") Signed-off-by: Jose Ignacio Tornos Martinez --- v5 Address the comments from Aleksandr Loktionov: - Error handling when ice_setup_vf_trust is called is not necessary because ice_vf_clear_all_promisc_modes is not used due to the conservative approach to solve AI tool review concerns - kdoc should end with '*/' not '**/' (new function) Address AI review (sashiko.dev) from Simon Horman: - Adopt a conservative approach checking multiple conditions before skipping reset: MAC LLDP filters, promiscuous mode - Simplify helper function to only handle capability flag - No need to export ice_vf_clear_all_promisc_modes v4: https://lore.kernel.org/all/20260423130405.139568-5-jtornosm@redhat.com/ drivers/net/ethernet/intel/ice/ice_sriov.c | 33 +++++++++++++++++++--- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c index 7e00e091756d..3c64ed1b41a8 100644 --- a/drivers/net/ethernet/intel/ice/ice_sriov.c +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c @@ -1364,6 +1364,23 @@ int ice_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac) return __ice_set_vf_mac(ice_netdev_to_pf(netdev), vf_id, mac); } +/** + * ice_setup_vf_trust - Enable/disable VF trust mode without reset + * @vf: VF to configure + * @setting: trust setting + * + * Update VF flags when changing trust without performing a VF reset. + * This is only called when it's safe to skip the reset (VF has no advanced + * features configured that need cleanup). + */ +static void ice_setup_vf_trust(struct ice_vf *vf, bool setting) +{ + if (setting) + set_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps); + else + clear_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps); +} + /** * ice_set_vf_trust * @netdev: network interface device structure @@ -1399,11 +1416,19 @@ 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 and VF has advanced features configured */ + if (!trusted && + (vf->num_mac_lldp > 0 || + test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) || + test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states))) { + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY); + 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); + } 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"); -- 2.53.0