From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) (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 6BBF732FA1B; Tue, 30 Jun 2026 22:59:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.155 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782860345; cv=none; b=Lb7l//Np1+fGln9DjIXfiyO+dFxdAKZcrInCeobKlj2bbihPzDLlfAq2d5ORFd/LF5iSe+yq+Szip0SWqGjtMcJntBL3LuTsa2k+Zt6d4Im6OYfuHO2gce/230lvfl+1QuwX0pNL1cZ3Lk8KO226ZCmefMFiYjjqvRmiQs01+K4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782860345; c=relaxed/simple; bh=HkHf36jpWBSbPhOI9+BlVy0yj3oNXJ2ScHBlT4g2Ykw=; h=From:To:cc:Subject:In-reply-to:References:MIME-Version: Content-Type:Date:Message-ID; b=KjjXfAo3eI+r0QvOYiNX4iVH1ImSB9Ru6xYNh8IMYvXX3S3K8nhmzzcry2k5vJ8prGY3w08wvzWy+GAGbDsHcc5FpKbBGAF5h4DEnmAfVf51oPrhKszYrgZCW7q7pUkzugOWzbaOUQrVDwG1iGwKhihvGz2a6YctcOPfKWImdEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=jvosburgh.net; spf=pass smtp.mailfrom=jvosburgh.net; dkim=pass (2048-bit key) header.d=jvosburgh.net header.i=@jvosburgh.net header.b=fyKJdU8x; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=fB3CzQhw; arc=none smtp.client-ip=103.168.172.155 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=jvosburgh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=jvosburgh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=jvosburgh.net header.i=@jvosburgh.net header.b="fyKJdU8x"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="fB3CzQhw" Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 788331400155; Tue, 30 Jun 2026 18:59:02 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Tue, 30 Jun 2026 18:59:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvosburgh.net; h=cc:cc:content-id:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1782860342; x= 1782946742; bh=Y6/Zgv2EAl9gLYe6n45/Fj/bRUykpuAHQNGEahXM/Fw=; b=f yKJdU8xc7g+NbyNpimhrGu/ESkmOiau/sI+Rj+KYSRs9TzgBMj+Yy5JxxaBH78Ba LX8mgB0jziyUJmyPuEpzrSNW0dDLWmnLBaqBPerNnxVcWVEiK+/p2NVvJsVJkdGC zuOfKc2zIFBtrVIJJCc2IDm/vCJx5QgkdacnSxAJMP621mApehnwSLGs8oy5laUc oh1o6EefllZmdeY2t7hfBNvlz1u9WERifIXV6DJW/7mgKcUYT1nETcDccbYBD0mo d7+HBKE5qc3v+BixAUesvRNOk4uqxiGrJ9A29vkqm7elqczJGX+kHdjMyw98OoW2 aXQWgAGJYqWyIYhyCJcKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-id:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1782860342; x=1782946742; bh=Y 6/Zgv2EAl9gLYe6n45/Fj/bRUykpuAHQNGEahXM/Fw=; b=fB3CzQhws62Gz8VOR 8dlXFhD10XO8EXKBhnq6PKJaZpdn4zW8aHjGUCEYgam8y4BO8IHJCmlhlEV8JCal qCe6bKop9kcuuZGc8biKM6+Zj/DdOsnRDMzVVbrKsMMnvYJmxNuc97j5PsbFyqpp ssgNFaq3uDmOr4xp+oTQtkaux3Iovti31d8kR4R/FgFUnzGGsf8TVNP6CaNqoCj1 8w421nAUfqQllVhu6pyt5w+ycqaASH5StOYVkgbvFJB69ON456BhOw2VLFk83muE 7xdTVLxvnyA/OYuSWMS/ckx3GlgtbYjZVxmOpaEO9YEMt54/PfgSS5Mdp38Vr3SH Aj1lQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFTCyQAfWYDemlxUx4YqR+3PjSq0FDg5PiuVvmR0XrgpUv20vbl+GYngsLKybtXlJ aq2liW8irkXfHFLWni5f17wlz0AgWclfEA79DIIaCt93h4MlRFiymjSXseEleN2+VNcbPm eTH0DOPcmwbygkxndcvBp588c4Fy2mIb/H9cdGRMRloBHuMsCtbAaOqc0ARHgx+ttvCSm/ xU+vpZscgxiVmIkDdw5JH26WswdwPG1cAs4lei5DYUm7etfM6H1Shdxv9N2mGzXHo+Qv7S s7oqQ940o7+vuov2GriQWjyh83B19eU09Aj6A4nSmonl/h27AOPjLy1dH9wdnnZwLja0Ka 57r1JCHEcKDnO8adCQ6rKUMd6f5U8VNHUIrX03v7MyHSmR14bmk8wuQDapK/lUdjgMW4Xc 5AO9j6RRM24gcd3FfsmvHUsyappRi0U/HrsQTj7R1enySXz3SyYHJzg0OvAJ6HQH4he/Fl DCuzdhwVDx9lIoGt05PYYCYTfb8LacdagaQfetdDhfwNh2l1S2VOhju7vgx3zmt4wQkVrZ Vog7sVT0X4/92pERyhhXsLe3oZPS1zD9MsplfJoAYrX5UZYR/EBrQN/+mKjuAwMJswSzEf MDnSSwUg/K9g3Xbb6PoOObk21EiLHnSVegGe9C2+H3QUim1MwA63LONz667g X-ME-Proxy: Feedback-ID: i53714940:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 Jun 2026 18:59:02 -0400 (EDT) Received: by famine.localdomain (Postfix, from userid 1000) id 20F9F9FC67; Tue, 30 Jun 2026 15:59:01 -0700 (PDT) Received: from famine (localhost [127.0.0.1]) by famine.localdomain (Postfix) with ESMTP id 1E4129FC4E; Tue, 30 Jun 2026 15:59:01 -0700 (PDT) From: Jay Vosburgh To: Paritosh Potukuchi cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, paritosh.potukuchi@amd.com Subject: Re: [RFC net-next] bonding: Retry updating slave MAC after a failure In-reply-to: <20260630150937.3508222-1-paritosh.potukuchi@amd.com> References: <20260630150937.3508222-1-paritosh.potukuchi@amd.com> Comments: In-reply-to Paritosh Potukuchi message dated "Tue, 30 Jun 2026 15:09:37 -0000." X-Mailer: MH-E 8.6+git; nmh 1.8+dev; Emacs 29.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2001255.1782860341.1@famine> Date: Tue, 30 Jun 2026 15:59:01 -0700 Message-ID: <2001256.1782860341@famine> Paritosh Potukuchi wrote: >I came across this TODO in bond_set_mac_address() : > > /* TODO: consider downing the slave > * and retry ? > * User should expect communications > * breakage anyway until ARP finish > * updating, so... > */ > >Currently, if the dev_set_mac_address() fails on a slave, we go >ahead and unwind the bond and its slaves. > >As the TODO suggests, one possible solution is to try setting >the MAC again, after putting down the interface. This is because some >drivers may reject changing the MAC when the device is UP. > >The solution I am proposing is as follows: > >dev_set_mac_address on the slave > - If this fails, temporarily stop the slave - ndo_stop > - If stop fails, unwind > - call dev_set_mac_address() on the slave > - If this fails, unwind > - Bring up the slave by calling ndo_open > - If this fails, unwind >If dev_set_mac_address on slave passes, we go to the next slave > > >Before working on a patch, I wanted to get feedback on whether >this interpretation of the TODO makes sense and whether there >are concerns with temporarily stopping and restarting a slave >during bond_set_mac_address(). I think the proper thing to do is remove this comment block and make no other changes. This comment dates to sometime before git, when it was common for network device drivers to lack the ability to change the MAC while the interface is up. To the best of my knowledge, that isn't a issue today. -J --- -Jay Vosburgh, jv@jvosburgh.net