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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (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 5B35FED7BBC for ; Tue, 14 Apr 2026 11:00:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2783984C16; Tue, 14 Apr 2026 11:00:27 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id RHvFb0-Ueuwo; Tue, 14 Apr 2026 11:00: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 smtp1.osuosl.org 57C8E84C12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1776164426; bh=emzWbgDp3sl38KudWkGi0QqDELafGTENdfL9dcFHDWg=; h=From:To:Cc:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=yezwE48ffwSCNX09rMQcoOdgbRnvxyxoQXTaoIldLEZuBBeITtmCg5PB3Mv5QwTHV l+pG0xQ7sgimUHqMf7XcTjrRvmHgplWmc60p03O+XJ2HKbaKpSTIRPbsxKXlZ5xloI iRXFxkNmRhkTUTGV4JpHxH2bsCaC4ZkLPw0J29bGN94Wo6+K9twYSYeef0purtOqhm hl3eSMrJFy5kuec2ueEY+yKrudRJUBrxb698M57Jzo2WGeDKg3uxLMWENh7KM6xosp IdTgMUjylk46uM3/iUAybaMXF0zrSLkbF96YpeJjng2TMXxLLfcT9fG3Tz+vljl6tW CryYvjn+NtmRQ== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp1.osuosl.org (Postfix) with ESMTP id 57C8E84C12; Tue, 14 Apr 2026 11:00:26 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists1.osuosl.org (Postfix) with ESMTP id F29BE237 for ; Tue, 14 Apr 2026 11:00:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E4A0E84C12 for ; Tue, 14 Apr 2026 11:00:24 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id hV4Fmxba2FcN for ; Tue, 14 Apr 2026 11:00:23 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=170.10.133.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=jtornosm@redhat.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org 9218084C0F DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9218084C0F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9218084C0F for ; Tue, 14 Apr 2026 11:00:21 +0000 (UTC) Received: from mx-prod-mc-06.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-348-RTSsLGbwPiSxHh2TbH7NIw-1; Tue, 14 Apr 2026 07:00:16 -0400 X-MC-Unique: RTSsLGbwPiSxHh2TbH7NIw-1 X-Mimecast-MFC-AGG-ID: RTSsLGbwPiSxHh2TbH7NIw_1776164415 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A63C41800365; Tue, 14 Apr 2026 11:00:14 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.48.43]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id ED6863000C16; Tue, 14 Apr 2026 11:00:10 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: netdev@vger.kernel.org Cc: intel-wired-lan@lists.osuosl.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: Tue, 14 Apr 2026 13:00:01 +0200 Message-ID: <20260414110006.124286-1-jtornosm@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: XlTx9nCliHQmwkZjodwsbbpMPAB8xJyHF_dSV3dXwpY_1776164415 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=1776164420; 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; bh=emzWbgDp3sl38KudWkGi0QqDELafGTENdfL9dcFHDWg=; b=EXAh3eQSQy48SMD67QHyyvsV5Y7jegEFl02XUIEIpzmpM/UycYtiqeJnGXXzMcyo4mUgf9 Wfgri2ucyBEvVsTs4nAeNR08DaTFo1Mm3LoMkyABl5UoTMormnDBAFMG9DIrdBinnAY9pJ RsbMn1qXsXMglTinbH9uo6i2bHtsbok= X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=EXAh3eQS Subject: [Intel-wired-lan] [PATCH net v3 0/5] Fix i40e/ice/iavf VF bonding after netdev lock changes 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" This series fixes VF bonding failures introduced by commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"). When adding VFs to a bond immediately after setting trust mode, MAC address changes fail with -EAGAIN, preventing bonding setup. This affects both i40e (700-series) and ice (800-series) Intel NICs. The core issue is lock contention: iavf_set_mac() is now called with the netdev lock held and waits for MAC change completion while holding it. However, both the watchdog task that sends the request and the adminq_task that processes PF responses also need this lock, creating a deadlock where neither can run, causing timeouts. Additionally, setting VF trust triggers an unnecessary ~10 second VF reset in i40e driver that delays bonding setup, even though filter synchronization happens naturally during normal VF operation. For ice driver, the delay is not so big, but in the same way the operation is not necessary. This series: 1. Adds safety guard to prevent MAC changes during reset or early initialization (before VF is ready) 2. Eliminates unnecessary VF reset when setting trust in i40e 3. Fixes lock contention by polling admin queue synchronously 4. Eliminates unnecessary VF reset when setting trust in ice 5. Refactors virtchnl polling to unify init-time and runtime code paths The key fix (patch 3/5) implements a synchronous MAC change operation similar to the approach used for ndo_change_mtu deadlock fix: https://lore.kernel.org/intel-wired-lan/20260211191855.1532226-1-poros@redhat.com/ Instead of scheduling work and waiting, it: - Sends the virtchnl message directly (not via watchdog) - Polls the admin queue hardware directly for responses - Processes all messages inline (including non-MAC messages) - Returns when complete or times out This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. A new generic iavf_poll_virtchnl_response() function was introduced for this. Patch 5 refactors the polling implementation based on Przemek Kitszel feedback, unifying in a centralized polling way, the previously (with patch 3) separate init-time (avf_poll_virtchnl_msg()) and runtime polling (iavf_poll_virtchnl_response()) into the original polling function (iavf_poll_virtchnl_msg()) allowing both behaviors. I have preferred to create a separate patch for the refactoring for the sake of clarity in the solution, and I would prefer to include in the net series because it is tightly coupled with patch 3. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. Testing shows VF bonding now works reliably in ~5 seconds vs 15+ seconds before (i40e), without timeouts or errors (i40e and ice). Tested on Intel 700-series (i40e) and 800-series (ice) dual-port NICs with iavf driver. Thanks to Jan Tluka and Yuying Ma for reporting the issues. Jose Ignacio Tornos Martinez (5): iavf: return EBUSY if reset in progress or not ready during MAC change i40e: skip unnecessary VF reset when setting trust iavf: send MAC change request synchronously ice: skip unnecessary VF reset when setting trust iavf: refactor virtchnl polling to unify init and runtime paths --- v3: - Complete patch 3 with the comments from Przemek Kitszel - Added patch 5: Refactor to unify polling into iavf_poll_virtchnl_msg() function (Przemek Kitszel suggestion). It processes messages through iavf_virtchnl_completion() when appropriate (runtime operations with timeout; init-time operations continue to return raw messages without completion processing). - No changes to patch 1,2 and 4 from v2 v2: https://lore.kernel.org/netdev/20260407165206.1121317-1-jtornosm@redhat.com/ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++- drivers/net/ethernet/intel/iavf/iavf.h | 6 +++++- drivers/net/ethernet/intel/iavf/iavf_main.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------- drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------- drivers/net/ethernet/intel/ice/ice_sriov.c | 13 +++++++++---- 5 files changed, 193 insertions(+), 64 deletions(-) -- 2.43.0