netdev - Re: [PATCH net-next v14 0/7] bonding: Extend arp_ip_target format to allow for a list of vlan tags.

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: <aRQsxwgtra6L5cQz@fedora>
Date: Wed, 12 Nov 2025 06:44:23 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: David Wilder <wilder@...ibm.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	jv@...sburgh.net, pradeep@...ibm.com, i.maximets@....org,
	amorenoz@...hat.com, haliu@...hat.com, stephen@...workplumber.org,
	horms@...nel.org, pabeni@...hat.com, andrew+netdev@...n.ch,
	edumazet@...gle.com, razor@...ckwall.org, shuah@...nel.org,
	corbet@....net, linux-kselftest@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next v14 0/7] bonding: Extend arp_ip_target format to
 allow for a list of vlan tags.

On Wed, Oct 22, 2025 at 05:50:33PM -0700, Jakub Kicinski wrote:
> On Wed, 22 Oct 2025 11:25:27 -0700 David Wilder wrote:
> > The current implementation of the arp monitor builds a list of vlan-tags by
> > following the chain of net_devices above the bond. See bond_verify_device_path().
> > Unfortunately, with some configurations, this is not possible. One example is
> > when an ovs switch is configured above the bond.
> 
> Once again if anyone thinks this belongs in the kernel please speak up.
> Otherwise let this be the last posting.
> 
> *If* someone does speak up in support you will need to find a less ugly
> way to represent the attribute within Netlink. What you invent must work
> in YNL and be added to the spec (Documentation/netlink/specs/rt-link.yaml)

Hi David,

I haven’t tested it yet, but for the netlink part, instead of using a
randomly sized binary structure, maybe you could try using nested attributes.
For example:

IFLA_BOND_ARP_IP_TARGET (nested)
 ├── [0] = 192.168.1.1              old format (no VLAN)
 ├── [1] (nested)                   new format (with VLAN tags)
 │     ├── IFLA_BOND_ARP_TARGET_IP = 192.168.2.1
 │     └── IFLA_BOND_ARP_TARGET_VLANS (nested)
 │           ├── [0] = 10
 │           ├── [1] = 20
 │           └── [2] = 30
 ├── [2] (nested)                   new format (no VLAN tags: leave empty or use nla_put_empty_nest())
 │     └── IFLA_BOND_ARP_TARGET_IP = 192.168.3.1

When parsing the attributes, first check if the data is nested using:
nla_type(attr) & NLA_F_NESTED. If not, just copy the IPv4 addresses.

If it’s nested, handle the target IP and VLANs accordingly.
The downside is that this approach would introduce three levels of nesting,
which might not be ideal.

Thanks
Hangbin