Netdev List
 help / color / mirror / Atom feed
* [RFC net-next] bonding: Retry updating slave MAC after a failure
@ 2026-06-30 15:09 Paritosh Potukuchi
  2026-06-30 22:59 ` Jay Vosburgh
  0 siblings, 1 reply; 3+ messages in thread
From: Paritosh Potukuchi @ 2026-06-30 15:09 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel, paritosh.potukuchi


Hi all,

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().

Thanks,
Paritosh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC net-next] bonding: Retry updating slave MAC after a failure
  2026-06-30 15:09 [RFC net-next] bonding: Retry updating slave MAC after a failure Paritosh Potukuchi
@ 2026-06-30 22:59 ` Jay Vosburgh
  2026-07-01  7:45   ` Paritosh Potukuchi
  0 siblings, 1 reply; 3+ messages in thread
From: Jay Vosburgh @ 2026-06-30 22:59 UTC (permalink / raw)
  To: Paritosh Potukuchi; +Cc: netdev, linux-kernel, paritosh.potukuchi

Paritosh Potukuchi <paritoshpotukuchi@gmail.com> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC net-next] bonding: Retry updating slave MAC after a failure
  2026-06-30 22:59 ` Jay Vosburgh
@ 2026-07-01  7:45   ` Paritosh Potukuchi
  0 siblings, 0 replies; 3+ messages in thread
From: Paritosh Potukuchi @ 2026-07-01  7:45 UTC (permalink / raw)
  To: Jay Vosburgh; +Cc: netdev, linux-kernel, paritosh.potukuchi

> 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.

Sure Jay. That makes sense. Should I go ahead and post a patch
removing this comment?

-Paritosh


On Wed, 1 Jul 2026 at 04:29, Jay Vosburgh <jv@jvosburgh.net> wrote:
>
> Paritosh Potukuchi <paritoshpotukuchi@gmail.com> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-07-01  7:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-30 15:09 [RFC net-next] bonding: Retry updating slave MAC after a failure Paritosh Potukuchi
2026-06-30 22:59 ` Jay Vosburgh
2026-07-01  7:45   ` Paritosh Potukuchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox