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

+ Linus Lüssing

Original patch: https://lore.kernel.org/netdev/20250912223937.1363559-1-Joseph.Huang@garmin.com/ (local)

On Mon, Sep 15, 2025 at 06:41:19PM -0400, Huang, Joseph wrote:

It seems that inet6addr_notifier_call_chain() can be called when the address
is still tentative, which means br_ip6_multicast_alloc_query() is still
going to fail (br_ip6_multicast_alloc_query() calls ipv6_dev_get_saddr(),
which calls __ipv6_dev_get_saddr(), which does not consider tentative source
addresses).

What the bridge needs really is a notification after DAD is completed, but I
couldn't find such notification. Or did you mean reusing the same
notification inet6addr_notifier_call_chain() but with a new event after DAD
is completed?

Adding a new event to the inet6addr notification chain makes more sense
than adding a new event to the netdev notification chain.

But before making changes, I want to better understand the problem you
are seeing. Is it specific to the offloaded data path? I believe the
problem was fixed in the software data path by this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0888d5f3c0f183ea6177355752ada433d370ac89

And Linus is working [1][2] on reflecting it to device drivers so that
the hardware data path will act like the software data path and flood
unregistered multicast traffic to all the ports as long as no querier
was detected.

As a temporary workaround, you can either configure an IPv6 link-local
address on the bridge before opening it:

 # ip -6 address add fe80::1/64 dev br0 nodad

Or enable optimistic DAD:

 # sysctl -wq net.ipv6.conf.br0.optimistic_dad=1

[1] https://lore.kernel.org/netdev/20250522195952.29265-1-linus.luessing@c0d3.blue/ (local)
[2] https://lore.kernel.org/netdev/20250829085724.24230-1-linus.luessing@c0d3.blue/ (local)