netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>, Liang Li <liali@redhat.com>,
	Jiri Pirko <jiri@nvidia.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	susan.zheng@veritas.com
Subject: Re: [PATCH net 1/3] bonding: fix macvlan over alb bond support
Date: Mon, 21 Aug 2023 15:54:10 -0700	[thread overview]
Message-ID: <1121.1692658450@famine> (raw)
In-Reply-To: <20230819090109.14467-2-liuhangbin@gmail.com>

Hangbin Liu <liuhangbin@gmail.com> wrote:

>The commit 14af9963ba1e ("bonding: Support macvlans on top of tlb/rlb mode
>bonds") aims to enable the use of macvlans on top of rlb bond mode. However,
>the current rlb bond mode only handles ARP packets to update remote neighbor
>entries. This causes an issue when a macvlan is on top of the bond, and
>remote devices send packets to the macvlan using the bond's MAC address
>as the destination. After delivering the packets to the macvlan, the macvlan
>will rejects them as the MAC address is incorrect. Consequently, this commit
>makes macvlan over bond non-functional.
>
>To address this problem, one potential solution is to check for the presence
>of a macvlan port on the bond device using netif_is_macvlan_port(bond->dev)
>and return NULL in the rlb_arp_xmit() function. However, this approach
>doesn't fully resolve the situation when a VLAN exists between the bond and
>macvlan.
>
>So let's just do a partial revert for commit 14af9963ba1e in rlb_arp_xmit().
>As the comment said, Don't modify or load balance ARPs that do not originate
>locally.
>
>Fixes: 14af9963ba1e ("bonding: Support macvlans on top of tlb/rlb mode bonds")
>Reported-by: susan.zheng@veritas.com
>Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2117816
>Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>---
> drivers/net/bonding/bond_alb.c |  4 ++--
> include/net/bonding.h          | 11 +----------
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>index b9dbad3a8af8..7765616107e5 100644
>--- a/drivers/net/bonding/bond_alb.c
>+++ b/drivers/net/bonding/bond_alb.c
>@@ -661,9 +661,9 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
> 	arp = (struct arp_pkt *)skb_network_header(skb);
> 
> 	/* Don't modify or load balance ARPs that do not originate locally
>-	 * (e.g.,arrive via a bridge).
>+	 * (e.g.,arrive via a bridge or macvlan).
> 	 */

	I agree that this is best way to handle this case.  This might
be nitpicking, but I think the comment would be clearer if it didn't
give examples of what is excluded, but instead lists only the things
that are included.  Perhaps something like:

 	/* Don't modify or load balance ARPs that do not originate
	 * from the bond itself or a VLAN directly above the bond.
	 */

	-J

>-	if (!bond_slave_has_mac_rx(bond, arp->mac_src))
>+	if (!bond_slave_has_mac_rcu(bond, arp->mac_src))
> 		return NULL;
> 
> 	dev = ip_dev_find(dev_net(bond->dev), arp->ip_src);
>diff --git a/include/net/bonding.h b/include/net/bonding.h
>index 30ac427cf0c6..5b8b1b644a2d 100644
>--- a/include/net/bonding.h
>+++ b/include/net/bonding.h
>@@ -722,23 +722,14 @@ static inline struct slave *bond_slave_has_mac(struct bonding *bond,
> }
> 
> /* Caller must hold rcu_read_lock() for read */
>-static inline bool bond_slave_has_mac_rx(struct bonding *bond, const u8 *mac)
>+static inline bool bond_slave_has_mac_rcu(struct bonding *bond, const u8 *mac)
> {
> 	struct list_head *iter;
> 	struct slave *tmp;
>-	struct netdev_hw_addr *ha;
> 
> 	bond_for_each_slave_rcu(bond, tmp, iter)
> 		if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
> 			return true;
>-
>-	if (netdev_uc_empty(bond->dev))
>-		return false;
>-
>-	netdev_for_each_uc_addr(ha, bond->dev)
>-		if (ether_addr_equal_64bits(mac, ha->addr))
>-			return true;
>-
> 	return false;
> }
> 
>-- 
>2.41.0
>
>

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

  reply	other threads:[~2023-08-21 22:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19  9:01 [PATCH net 0/3] bonding: fix macvlan over alb bond support Hangbin Liu
2023-08-19  9:01 ` [PATCH net 1/3] " Hangbin Liu
2023-08-21 22:54   ` Jay Vosburgh [this message]
2023-08-19  9:01 ` [PATCH net 2/3] selftest: bond: add new topo bond_topo_2d1c.sh Hangbin Liu
2023-08-19  9:01 ` [PATCH net 3/3] selftests: bonding: add macvlan over bond testing 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=1121.1692658450@famine \
    --to=jay.vosburgh@canonical.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=liali@redhat.com \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=susan.zheng@veritas.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).