From nobody Sun Feb 8 01:21:30 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 013B62765DC for ; Mon, 2 Feb 2026 08:48:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770022116; cv=none; b=J8EX/GxL4aUHn7k6WQsv4dkyX8ljDZ+OoXZoepK0G9mWkCR9wXJ9Rxps6ps9UyQq6Ifiyw+7sC5eCJgbrbNE44Vut7prEenE3j8VZQZP0aVy6tJeZg0oh4Hc4IHqhVSO2ir2/Ajl6QjMLWB8axY9T79HSG/WEqyJAANsKt4eF/U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770022116; c=relaxed/simple; bh=DmkFICASqUCuaw1zsTrqq3F5bMziojXG5teY9pvx6LE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ondW7s2tcUkJCTI8KDasa4DOvi2KFiPkqc/dFGbkJ93VtQXQBBSLTOrVbeKCSEeoltFTqe+inH8/0pVAaWQ6F86W4eSZ3unHRcVc+R2/YXIpIOl8nZE0J5LVzo9PYxsfxLVfNpjg0CEipKJl2pAvhcEGX4XEwYp8QsxtkegxS98= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JQ9grjr5; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JQ9grjr5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770022114; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HTwQrQT+ZoBH+fw1ExFDWdLwscSVJv6fNBdaB+KAnVs=; b=JQ9grjr5Daqt4K/A4iR2atn/m/GAi5WflLhvY17xMRV7Ro4c1NqwTPAQRpZcT+MQwL+kAk rtkV4BSBC31MDp5XWtFCrZJgUeaH9JsNSRMcy5nOIydqZNCx4sWtYdwNrXvNuRowdhWk9i 8gx99HVdkmpkhAl6uiePoZ6vpo2jUYs= 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-529-t_tByHraPmeWlBukj8Y70w-1; Mon, 02 Feb 2026 03:48:29 -0500 X-MC-Unique: t_tByHraPmeWlBukj8Y70w-1 X-Mimecast-MFC-AGG-ID: t_tByHraPmeWlBukj8Y70w_1770022108 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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 ED371180047F; Mon, 2 Feb 2026 08:48:27 +0000 (UTC) Received: from ShadowPeak.redhat.com (unknown [10.44.32.10]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 146911956053; Mon, 2 Feb 2026 08:48:23 +0000 (UTC) From: Petr Oros To: netdev@vger.kernel.org Cc: ivecera@redhat.com, mschmidt@redhat.com, Petr Oros , Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Stanislav Fomichev , intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org Subject: [PATCH net] iavf: fix deadlock in reset handling Date: Mon, 2 Feb 2026 09:48:20 +0100 Message-ID: <20260202084820.260033-1-poros@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 Content-Type: text/plain; charset="utf-8" Three driver callbacks schedule a reset and wait for its completion: ndo_change_mtu(), ethtool set_ringparam(), and ethtool set_channels(). Waiting for reset in ndo_change_mtu() and set_ringparam() was added by commit c2ed2403f12c74 ("iavf: Wait for reset in callbacks which trigger it") to fix a race condition where adding an interface to bonding immediately after MTU or ring parameter change failed because the interface was still in __RESETTING state. The same commit also added waiting in iavf_set_priv_flags(), which was later removed by commit 53844673d55529 ("iavf: kill "legacy-rx" for good"). Waiting in set_channels() was introduced earlier by commit 4e5e6b5d9d13 ("iavf: Fix return of set the new channel count") to ensure the PF has enough time to complete the VF reset when changing channel count, and to return correct error codes to userspace. Commit ef490bbb226702 ("iavf: Add net_shaper_ops support") added net_shaper_ops to iavf, which required reset_task to use _locked NAPI variants (napi_enable_locked, napi_disable_locked) that need the netdev instance lock. Later, commit 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") and commit 2bcf4772e45adb ("net: ethtool: try to protect all callback with netdev instance lock") started holding the netdev instance lock during ndo and ethtool callbacks for drivers with net_shaper_ops. The combination of waiting for reset and the new locking requirements creates a deadlock: the callback holds the lock and waits for reset_task, but reset_task is blocked waiting for the same lock: Thread 1 (callback) Thread 2 (reset_task) ------------------- --------------------- netdev_lock() ndo_change_mtu() or ethtool op iavf_schedule_reset() iavf_wait_for_reset() iavf_reset_task() waiting... netdev_lock() <- DEADLOCK Reproducer: # echo 16 > /sys/class/net/$PF/device/sriov_numvfs # ip link set $VF up # ip link set $VF mtu 5000 RTNETLINK answers: Device or resource busy # dmesg | tail -1 iavf: MTU change interrupted waiting for reset Fix this by temporarily releasing the lock while waiting for reset to complete. This follows the pattern used elsewhere in the kernel (e.g., do_set_master() releases rtnl_lock before calling ndo_add_slave()). Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink opera= tions") Signed-off-by: Petr Oros Reviewed-by: Aleksandr Loktionov Reviewed-by: Ivan Vecera Reviewed-by: Jijie Shao --- drivers/net/ethernet/intel/iavf/iavf_main.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethe= rnet/intel/iavf/iavf_main.c index 8aa6e92c16431f..d7738fb8fa60bc 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -189,13 +189,22 @@ static bool iavf_is_reset_in_progress(struct iavf_ada= pter *adapter) * iavf_wait_for_reset - Wait for reset to finish. * @adapter: board private structure * + * The iavf driver selects NET_SHAPER, so callbacks that trigger reset are + * always called with netdev instance lock held, while reset_task also nee= ds + * this lock. Release the lock while waiting to avoid deadlock. + * * Returns 0 if reset finished successfully, negative on timeout or interr= upt. */ int iavf_wait_for_reset(struct iavf_adapter *adapter) { - int ret =3D wait_event_interruptible_timeout(adapter->reset_waitqueue, - !iavf_is_reset_in_progress(adapter), - msecs_to_jiffies(5000)); + struct net_device *netdev =3D adapter->netdev; + int ret; + + netdev_unlock(netdev); + ret =3D wait_event_interruptible_timeout(adapter->reset_waitqueue, + !iavf_is_reset_in_progress(adapter), + msecs_to_jiffies(5000)); + netdev_lock(netdev); =20 /* If ret < 0 then it means wait was interrupted. * If ret =3D=3D 0 then it means we got a timeout while waiting --=20 2.52.0