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: <1102580.1761363890@famine>
Date: Fri, 24 Oct 2025 20:44:50 -0700
From: Jay Vosburgh <jv@...sburgh.net>
To: Jakub Kicinski <kuba@...nel.org>
cc: David Wilder <wilder@...ibm.com>, netdev@...r.kernel.org,
    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.

Jakub Kicinski <kuba@...nel.org> 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)
>-- 
>pw-bot: cr

	Sorry, didn't have a chance to catch up until now.  I gave this
a read through again, and I have mixed feelings about it.

	I understand the problem they're trying to solve, which is
largely an artifact of the way OVS kind of lives off to the side and
does its own thing.  And, yes, there are a bunch of other things (tc,
ebpf, et al) that can arbitrarily tweak VLAN tags in a packet.

	That said, it's kind of a niche use case, and it's adding what
feels to me like an awkward API and its related infrastructure that will
have to be maintained forever.  Bonding already has baggage from things
that seemed like a good idea at the time, but ultimately weren't, so I'm
reluctant to add something like this for a niche case.

	-J

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