netdev - Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

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: <aOZY5yYiKtfUrLZr@shredder>
Date: Wed, 8 Oct 2025 15:28:23 +0300
From: Ido Schimmel <idosch@...dia.com>
To: "Huang, Joseph" <joseph.huang.at.garmin@...il.com>,
	linus.luessing@...3.blue
Cc: Joseph Huang <Joseph.Huang@...min.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	David Ahern <dsahern@...nel.org>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Kuniyuki Iwashima <kuniyu@...gle.com>,
	Ahmed Zaki <ahmed.zaki@...el.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	linux-kernel@...r.kernel.org, bridge@...ts.linux.dev
Subject: Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

On Mon, Oct 06, 2025 at 11:43:02AM -0400, Huang, Joseph wrote:
> On 10/4/2025 10:27 AM, Linus Lüssing wrote:
> > However (at least for a non-hardware-offloaded) bridge as far as I
> > recall this shouldn't create any multicast packet loss and should
> > operate as "normal" with flooding multicast data packets first,
> > with multicast snooping activating on multicast data
> > after another IGMP/MLD querier interval has elapsed (default:
> > 125 sec.)?

Isn't this 10 seconds (default mcast_query_response_interval)?

BTW, I see that delay_timer is started in br_multicast_set_querier()
which is called from br_changelink(). Isn't this problematic if querier
is enabled while the bridge is administratively down? It's possible for
this timer to expire by the time the bridge is opened.

> Some systems could not afford to flood multicast traffic. Think of some
> resource-constrained low power sensors connected to a network with high
> volume multicast video traffic for example. The multicast traffic could
> easily choke the sensors and is essentially a DDoS attack.

Note that even with your patch (or optimistic DAD) there will still be a
time period where multicast traffic is flooded to give responses enough
time to arrive.

Can you clarify how you observed the problem? Did you observe packet
loss with hardware offload or did you observe excessive flooding with
the software data path?

> > Which indeed could be optimized and is confusing, this delay could
> > be avoided. Is that that the issue you mean, Joseph?
> > (I'd consider it more an optimization, so for net-next, not
> > net though.)
> > 
> 
> I'm not sure this should be categorized as an optimization. If we never
> intend to send Startup Queries, that's a different story. But if we intend
> to send it but failed, I think that should be a bug.

I would say that the deciding factor should be if it's a regression or
not.