netdev - RE: [PATCH net-next v13 6/7] bonding: Update for extended arp_ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <MW3PR15MB3913E83123930C417DDD1AC8FAE9A@MW3PR15MB3913.namprd15.prod.outlook.com>
Date: Fri, 17 Oct 2025 00:21:02 +0000
From: David Wilder <wilder@...ibm.com>
To: Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jv@...sburgh.net"
	<jv@...sburgh.net>,
        Pradeep Satyanarayana <pradeep@...ibm.com>,
        "i.maximets@....org" <i.maximets@....org>,
        Adrian Moreno Zapata
	<amorenoz@...hat.com>,
        Hangbin Liu <haliu@...hat.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "horms@...nel.org"
	<horms@...nel.org>,
        "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Nikolay Aleksandrov
	<razor@...ckwall.org>
Subject: RE: [PATCH net-next v13 6/7] bonding: Update for extended
 arp_ip_target format.

________________________________________
From: Jakub Kicinski <kuba@...nel.org>
Sent: Thursday, October 16, 2025 12:49 PM
To: Paolo Abeni
Cc: David Wilder; netdev@...r.kernel.org; jv@...sburgh.net; Pradeep Satyanarayana; i.maximets@....org; Adrian Moreno Zapata; Hangbin Liu; stephen@...workplumber.org; horms@...nel.org; andrew+netdev@...n.ch; edumazet@...gle.com
Subject: [EXTERNAL] Re: [PATCH net-next v13 6/7] bonding: Update for extended arp_ip_target format.

> On Thu, 16 Oct 2025 13:50:52 +0200 Paolo Abeni wrote:
> > > +           if (nla_put(skb, i, size, &data))
> > > +                   goto nla_put_failure;
> > >     }
> > >
> > >     if (targets_added)
> >
> > I guess you should update bond_get_size() accordingly???
> >
> > Also changing the binary layout of an existing NL type does not feel
> > safe. @Jakub: is that something we can safely allow?
>
> In general extending attributes is fine, but going from a scalar
> to a struct is questionable. YNL for example will not allow it.

I am not sure I understand your concern. I have change the
netlink socket payload from a fixed 4 bytes to a variable number of bytes.
4 bytes for ipv4 address followed by some number of bytes with the
list of vlans, could be zero. Netlink sockets just need to be told the
payload size.  Or have I missed the point?

>
> I haven't looked at the series more closely until now.
>
> Why are there multiple vlan tags per target?

You can have a vlan inside a vlan, the original arp_ip_target
option code supported this.

>
> Is this configuration really something we should support in the kernel?
> IDK how much we should push "OvS-compatibility" into other parts of the
> stack. If user knows that they have to apply this funny configuration
> on the bond maybe they should just arp from user space?

This change is not just for compatibility with OVS. Ilya Maximets pointed out:
"..this is true not only for OVS.  You can add various TC qdiscs onto the
interface that will break all those assumptions as well, for example.  Loaded
BPF/XDP programs will too."

When using the arp_ip_target option the bond driver must discover what
vlans are in the path to the target. These special arps must be generated by
the bonding driver to know what bonded slave the packets is to sent and
received on and at what frequency.

When the the arp_ip_target feature was first introduced discovering vlans in the
path to the target was easy by following the linked net_devices. As our
networking code has evolved this is no longer possible with all configurations
as Ilya pointed out.  What I have done is provide alternate way to provide the
list of vlans so this desirable feature can continue to function.

Regards
  David Wilder