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>, Jianbo Liu <jianbol@nvidia.com>,
	Boris Pismenny <borisp@nvidia.com>,
	Tariq Toukan <tariqt@nvidia.com>, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 net 1/2] bonding: fix incorrect MAC address setting to receive NS messages
Date: Thu, 06 Feb 2025 17:19:34 -0800	[thread overview]
Message-ID: <624905.1738891174@famine> (raw)
In-Reply-To: <20250206094600.357420-2-liuhangbin@gmail.com>

Hangbin Liu <liuhangbin@gmail.com> wrote:

>When validation on the backup slave is enabled, we need to validate the
>Neighbor Solicitation (NS) messages received on the backup slave. To
>receive these messages, the correct destination MAC address must be added
>to the slave. However, the target in bonding is a unicast address, which
>we cannot use directly. Instead, we should first convert it to a
>Solicited-Node Multicast Address and then derive the corresponding MAC
>address.
>
>Fixes: 8eb36164d1a6 ("bonding: add ns target multicast address to slave device")
>Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>

	I think this now deserves some commentary in the code.  Not
because this function itself is unclear, but because there's the
similarly-named slave_set_ns_maddr() (singular, not plural as in this
patch) that will behave in a subtly different manner after this patch is
applied.

	The "maddrs" version here will convert the provided IPv6 address
to the IPv6 solicited-nodes multicast address (RFC 4291 section 2.7.1)
and thence to the MAC address, via ndisc_mc_map(), whereas the "maddr"
version uses the supplied IPv6 address directly for multicast MAC
address conversion.

	Assuming that I'm following that correctly, I think this
distinction deserves explanation.  And if I'm getting it wrong, then it
definitely deserves some explanation.

	FWIW, functionally, I think it's doing the correct thing.

	-J

>---
> drivers/net/bonding/bond_options.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 327b6ecdc77e..63cf209dcdc9 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -1246,6 +1246,7 @@ static void slave_set_ns_maddrs(struct bonding *bond, struct slave *slave, bool
> {
> 	struct in6_addr *targets = bond->params.ns_targets;
> 	char slot_maddr[MAX_ADDR_LEN];
>+	struct in6_addr mcaddr;
> 	int i;
> 
> 	if (!slave_can_set_ns_maddr(bond, slave))
>@@ -1255,7 +1256,8 @@ static void slave_set_ns_maddrs(struct bonding *bond, struct slave *slave, bool
> 		if (ipv6_addr_any(&targets[i]))
> 			break;
> 
>-		if (!ndisc_mc_map(&targets[i], slot_maddr, slave->dev, 0)) {
>+		addrconf_addr_solict_mult(&targets[i], &mcaddr);
>+		if (!ndisc_mc_map(&mcaddr, slot_maddr, slave->dev, 0)) {
> 			if (add)
> 				dev_mc_add(slave->dev, slot_maddr);
> 			else
>-- 
>2.46.0
>

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

  reply	other threads:[~2025-02-07  1:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06  9:45 [PATCHv2 net 0/2] bonding: fix incorrect mac address setting Hangbin Liu
2025-02-06  9:45 ` [PATCHv2 net 1/2] bonding: fix incorrect MAC address setting to receive NS messages Hangbin Liu
2025-02-07  1:19   ` Jay Vosburgh [this message]
2025-02-07  7:31     ` Hangbin Liu
2025-02-06  9:46 ` [PATCHv2 net 2/2] selftests: bonding: fix incorrect mac address 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=624905.1738891174@famine \
    --to=jv@jvosburgh.net \
    --cc=andrew+netdev@lunn.ch \
    --cc=borisp@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jianbol@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=shuah@kernel.org \
    --cc=tariqt@nvidia.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 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.