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 884DFCDB46F for ; Tue, 23 Jun 2026 10:18:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 52F718176F; Tue, 23 Jun 2026 10:18: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 8eHxN6keJKzV; Tue, 23 Jun 2026 10:18: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 smtp1.osuosl.org 9478081750 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1782209903; bh=UUZZxE8nEXerLdqM7sMjYwt9oXDNzI3xWTJ5VDrRG4o=; h=From:To:Cc:Date:In-Reply-To:References:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Mlh7OuIKj9zdXChx+Tpis2ujXbHZtPE7uXOF1MUZ3dkDxwORPMYUSgnnehPm8QwOe TwUxvuvyL2cjtUyJ2BB76S8TDozbdXQWFPhayMxvZoqUwQE93KhNUYErfAOWThvQV4 1aONml/UW8apeYadS2ZErj+NGZailB8NqMQImYr1P+P3nRsLpAgWuM3NA4atoqYdOZ N0O9sfYkLSbiUUXchXJE2tFGyW6u+UirMGocrfPKrbIZhbcL4IeZxuqiUKeEwL7pnD DhStyiZDnfzoq+O/jCsoHTTmda13tqpmmhSXmqjOhvIJkHvnYZyiXxtA0N/HibUttP ma4yGVVwd4UIw== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp1.osuosl.org (Postfix) with ESMTP id 9478081750; Tue, 23 Jun 2026 10:18:23 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists1.osuosl.org (Postfix) with ESMTP id 6EED5256 for ; Tue, 23 Jun 2026 10:18:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6089B8175F for ; Tue, 23 Jun 2026 10:18:22 +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 Ira15kAgfB75 for ; Tue, 23 Jun 2026 10:18: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 smtp1.osuosl.org 4F88E81750 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4F88E81750 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4F88E81750 for ; Tue, 23 Jun 2026 10:18: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-453-OX98ry-TMPyGy2t15ZtE3Q-1; Tue, 23 Jun 2026 06:18:16 -0400 X-MC-Unique: OX98ry-TMPyGy2t15ZtE3Q-1 X-Mimecast-MFC-AGG-ID: OX98ry-TMPyGy2t15ZtE3Q_1782209895 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 CD5701802673; Tue, 23 Jun 2026 10:18:14 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.48.11]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B5BCB1800593; Tue, 23 Jun 2026 10:18:10 +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, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Jose Ignacio Tornos Martinez , Rafal Romanowski Date: Tue, 23 Jun 2026 12:17:57 +0200 Message-ID: <20260623101800.991293-2-jtornosm@redhat.com> In-Reply-To: <20260623101800.991293-1-jtornosm@redhat.com> References: <20260623101800.991293-1-jtornosm@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-MFC-PROC-ID: Qkf0FL3Zt1JrPi7_tLGOJu1Q8XtI3AVt0aqXOnkzOxY_1782209895 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=1782209900; 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=UUZZxE8nEXerLdqM7sMjYwt9oXDNzI3xWTJ5VDrRG4o=; b=JBWazFnzvsk3y5AloK9L7i0L+oADEiF7CzZGDkgGfOIEbjgmJE+0ZTJcsKPYoedl7g14Q/ PtEVC1VPWpfc0/FEg3vuRVvtP41MeAVwNYr8uWvwzkJCqMp4t8pqywc2AmiELeo3NhxSop 6h02aoXVaApWtU7UzPGWnjzFnuo1opI= 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=JBWazFnz Subject: [Intel-wired-lan] [PATCH net v7 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change 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" When a MAC address change is requested while the VF is resetting or still initializing, return -EBUSY immediately instead of attempting the operation. Additionally, during early initialization states (before __IAVF_DOWN), the PF may be slow to respond to MAC change requests, causing long delays. Only allow MAC changes once the VF reaches __IAVF_DOWN state or later, when the watchdog is running and the VF is ready for operations. After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), MAC changes are called with the netdev lock held, so we should not wait with the lock held during reset or initialization. This allows the caller to retry or handle the busy state appropriately without blocking other operations. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski --- v7: Rebase on current net tree (no code changes from v6) v6: https://lore.kernel.org/all/20260619061321.8554-2-jtornosm@redhat.com/ drivers/net/ethernet/intel/iavf/iavf_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c index dad001abc908..67aa14350b1b 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -1060,6 +1060,9 @@ static int iavf_set_mac(struct net_device *netdev, void *p) struct sockaddr *addr = p; int ret; + if (iavf_is_reset_in_progress(adapter) || adapter->state < __IAVF_DOWN) + return -EBUSY; + if (!is_valid_ether_addr(addr->sa_data)) return -EADDRNOTAVAIL; -- 2.53.0 From mboxrd@z Thu Jan 1 00:00:00 1970 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 0F48D375AB5 for ; Tue, 23 Jun 2026 10:18:20 +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=1782209902; cv=none; b=G2pQ9MAbrs8crSlI9c2bVKqRLxnC5JL8zdNrkKfLEWKJSzOaupKIVsrhFelKJel2+zbNsMuPayXtJWm3RD9BPtl4b6XDb/4hF0f3Xv60zHsQ8oimbCpluDDNO0RNXtAbSqd54ws6GBqReh0AwNqeQUY6rB25ezx6j/Jlt6mmsEQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782209902; c=relaxed/simple; bh=aO/08hh0b6kAbY6s3lf1TnMXs0Gv3Jwqj7BUH98kXM4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qM5FNZzr161TZIM5cnnkaAneWow8pbvb4dJeCajYFvM9Av7xRh3IK7I3Bzcb/FE2nZPhSjgKm+PxDWcfXTQWg54auH+emshUKUzKkbRp0znq2XWUB74LkpaMizAKlppuB58PiFNP3Bn0pRMdGrg0Cp1072lQnv1AkOR6IM4iB98= 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=NYFyj9/b; 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="NYFyj9/b" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782209900; 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: in-reply-to:in-reply-to:references:references; bh=UUZZxE8nEXerLdqM7sMjYwt9oXDNzI3xWTJ5VDrRG4o=; b=NYFyj9/bAFEg55dci6X36JJMNkY+0MHWQhizIDI8M6tBDSfNJYhwJJfwuPurXCeA2PZiku gxrQ157bvvOyBLy8X7j+Idfz/xod+2SjncZcJyDkZtkXCV+R4pdbhiVwr10J/lIk+Q6P9I C2AsqJPb8xoMbCRNIsDLpxURsYSc4WY= 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-453-OX98ry-TMPyGy2t15ZtE3Q-1; Tue, 23 Jun 2026 06:18:16 -0400 X-MC-Unique: OX98ry-TMPyGy2t15ZtE3Q-1 X-Mimecast-MFC-AGG-ID: OX98ry-TMPyGy2t15ZtE3Q_1782209895 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (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 CD5701802673; Tue, 23 Jun 2026 10:18:14 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.48.11]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B5BCB1800593; Tue, 23 Jun 2026 10:18:10 +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, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Jose Ignacio Tornos Martinez , Rafal Romanowski Subject: [PATCH net v7 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change Date: Tue, 23 Jun 2026 12:17:57 +0200 Message-ID: <20260623101800.991293-2-jtornosm@redhat.com> In-Reply-To: <20260623101800.991293-1-jtornosm@redhat.com> References: <20260623101800.991293-1-jtornosm@redhat.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 When a MAC address change is requested while the VF is resetting or still initializing, return -EBUSY immediately instead of attempting the operation. Additionally, during early initialization states (before __IAVF_DOWN), the PF may be slow to respond to MAC change requests, causing long delays. Only allow MAC changes once the VF reaches __IAVF_DOWN state or later, when the watchdog is running and the VF is ready for operations. After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), MAC changes are called with the netdev lock held, so we should not wait with the lock held during reset or initialization. This allows the caller to retry or handle the busy state appropriately without blocking other operations. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski --- v7: Rebase on current net tree (no code changes from v6) v6: https://lore.kernel.org/all/20260619061321.8554-2-jtornosm@redhat.com/ drivers/net/ethernet/intel/iavf/iavf_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c index dad001abc908..67aa14350b1b 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -1060,6 +1060,9 @@ static int iavf_set_mac(struct net_device *netdev, void *p) struct sockaddr *addr = p; int ret; + if (iavf_is_reset_in_progress(adapter) || adapter->state < __IAVF_DOWN) + return -EBUSY; + if (!is_valid_ether_addr(addr->sa_data)) return -EADDRNOTAVAIL; -- 2.53.0