[RFC net-next] bonding: Retry updating slave MAC after a failure

[RFC net-next] bonding: Retry updating slave MAC after a failure

[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

Re: [RFC net-next] bonding: Retry updating slave MAC after a failure

[Jay Vosburgh]

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

Re: [RFC net-next] bonding: Retry updating slave MAC after a failure

[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

Re: [RFC net-next] bonding: Retry updating slave MAC after a failure

[Jay Vosburgh]

Paritosh Potukuchi <paritoshpotukuchi@gmail.com> wrote:

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

	Yes, please do so.

	-J

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