On 3/2/26 12:08 PM, Ido Schimmel wrote:
On Sun, Mar 01, 2026 at 07:27:56PM +0100, Fernando Fernandez Mancera wrote:
On 2/28/26 9:30 PM, Jakub Kicinski wrote:
On Fri, 27 Feb 2026 00:40:59 +0100 Fernando Fernandez Mancera wrote:
Fix this by adding a check before br_is_local_ip6() or neigh_lookup()
call. If ipv6_stub->nd_tbl is NULL, return immediately.
The problem should probably be fixed by replacing IS_ENABLED(IPV6) in
the callers with ipv6_mod_enabled(), rather than randomly sprinkling
null checks?
I agree about using ipv6__mod_enabled() instead of the NULL check. Thanks
for that recommendation, although I do not agree with replacing
IS_ENABLED(IPV6) because here there is some ND message suppression that can
be applied and at the end bridge should not be look to L3 unless necessary.
E.g NUD is still being suppressed even if ipv6 is disabled on boot.
What do you think? Thanks.
I agree with Jakub and I believe it makes sense to not do any NS/NA
suppression when IPv6 is disabled. You are right that some messages can
be suppressed when IPv6 is disabled, but:
1. We are planning to send a patch to prevent the unconditional
suppression of ARP probes (DAD NS). Pending testing.
2. There are some cases where GARP (unsolicited NA) should not be
suppressed (see RFC 9161) and we plan to add a knob to control that.
3. It's unlikely that anyone is actually relying on this behavior.
Blamed commit is from 2017 and we only got a report now.
4. Suppression that can be done without the IPv6 module being loaded can
probably be achieved using stateless egress filters.
All right, given these arguments let's replace IS_ENABLED(IPV6) with
ipv6_mod_enabled().
Thank you for all the feedback!
Fernando.
