netdev - Re: [PATCH net-next v3] hv_netvsc: Set device flags for properly indicating bonding in Hyper-V

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: <20250211163735.18d0fd02@hermes.local>
Date: Tue, 11 Feb 2025 16:37:35 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: longli@...uxonhyperv.com, Jason Gunthorpe <jgg@...pe.ca>, Leon
 Romanovsky <leon@...nel.org>, Ajay Sharma <sharmaajay@...rosoft.com>,
 Konstantin Taranov <kotaranov@...rosoft.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org, Long Li
 <longli@...rosoft.com>
Subject: Re: [PATCH net-next v3] hv_netvsc: Set device flags for properly
 indicating bonding in Hyper-V

On Tue, 11 Feb 2025 16:20:26 -0800
Jakub Kicinski <kuba@...nel.org> wrote:

> On Fri,  7 Feb 2025 13:55:37 -0800 longli@...uxonhyperv.com wrote:
> > On Hyper-V platforms, a slave VF netdev always bonds to Netvsc and remains
> > as Netvsc's only active slave as long as the slave device is present. This
> > behavior is the same as a bonded device, but it's not user-configurable.
> > 
> > Some kernel APIs (e.g those in "include/linux/netdevice.h") check for
> > IFF_MASTER, IFF_SLAVE and IFF_BONDING for determing if those are used in
> > a master/slave bonded setup. Netvsc's bonding setup with its slave device
> > falls into this category.  
> 
> Again, this is way too much of a hack. You're trying to make
> netif_is_bond_master() return true for your franken-interfaces
> with minimal effort. 

Agree but disagree as to reasoning.

The way bonding is handled in the kernel internal API's is ad-hoc.
Really a better solution is needed.

The real problem is in any code (other than the bonding driver itself)
looking at IFF_BONDING is broken. All that code won't work if used over team
or failover devices (luckily no one ever seems to use them).