All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jv@jvosburgh.net>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, Qiuling Ren <qren@redhat.com>
Subject: Re: [PATCH net 1/2] bonding: set random address only when slaves already exist
Date: Fri, 22 Aug 2025 17:21:30 -0700	[thread overview]
Message-ID: <1546564.1755908490@famine> (raw)
In-Reply-To: <20250820091009.393785-1-liuhangbin@gmail.com>

Hangbin Liu <liuhangbin@gmail.com> wrote:

>Commit 5c3bf6cba791 ("bonding: assign random address if device address is
>same as bond") fixed an issue where, after releasing the first slave and
>re-adding it to the bond with fail_over_mac=follow, both the active and
>backup slaves could end up with duplicate MAC addresses. To avoid this,
>the new slave was assigned a random address.
>
>However, if this happens when adding the very first slave, the bond’s
>hardware address is set to match the slave’s. Later, during the
>fail_over_mac=follow check, the slave’s MAC is randomized because it
>naturally matches the bond, which is incorrect.

	The description here seems confusing to me; what does "this"
refer to?  I don't understand the sequence of events that lead to the
issue being fixed here.

	I wonder if there's another bug somewhere, since nominally when
releasing the last interface in the bond, __bond_release_one() should
randomize the bond's MAC address, so it shouldn't match when adding (or
re-adding ?) the first interface to the bond.

	-J

>The issue is normally hidden since the first slave usually becomes the
>active one, which restores the bond's MAC address. However, if another
>slave is selected as the initial active interface, the issue becomes visible.
>
>Fix this by assigning a random address only when slaves already exist in
>the bond.
>
>Fixes: 5c3bf6cba791 ("bonding: assign random address if device address is same as bond")
>Reported-by: Qiuling Ren <qren@redhat.com>
>Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>---
> drivers/net/bonding/bond_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 257333c88710..8832bc9f107b 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2132,6 +2132,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
> 		memcpy(ss.__data, bond_dev->dev_addr, bond_dev->addr_len);
> 	} else if (bond->params.fail_over_mac == BOND_FOM_FOLLOW &&
> 		   BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP &&
>+		   bond_has_slaves(bond) &&
> 		   memcmp(slave_dev->dev_addr, bond_dev->dev_addr, bond_dev->addr_len) == 0) {
> 		/* Set slave to random address to avoid duplicate mac
> 		 * address in later fail over.
>-- 
>2.50.1
>

---
	-Jay Vosburgh, jv@jvosburgh.net


  parent reply	other threads:[~2025-08-23  0:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20  9:10 [PATCH net 1/2] bonding: set random address only when slaves already exist Hangbin Liu
2025-08-20  9:10 ` [PATCH net 2/2] selftests: bonding: add fail_over_mac testing Hangbin Liu
2025-08-23  0:21 ` Jay Vosburgh [this message]
2025-08-25  4:07   ` [PATCH net 1/2] bonding: set random address only when slaves already exist Hangbin Liu
2025-09-09  3:34     ` Hangbin Liu
2025-09-09 20:25       ` Jay Vosburgh
2025-09-10  2:17         ` Hangbin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1546564.1755908490@famine \
    --to=jv@jvosburgh.net \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qren@redhat.com \
    --cc=razor@blackwall.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.