Re: [PATCH] ipv6: addrconf: drop "BUG: " prefix from pr_warn()

[AnishMulay <anishm7030@gmail.com>]

On Wed, Sep 09, 2026 at 02:56:55PM +0300, Ido Schimmel wrote:
> Does your reproducer rely on both keep_addr_on_down being set on the
> loopback device and its MTU going below 1280?
>
> The loopback device retains global addresses when this happens, unlike
> any other device [...]
>
> So, given that this state is quite broken and unlikely to be used by
> anyone other than fuzzers, I would like to simply align the loopback
> behavior with other devices and avoid keeping its addresses when the MTU
> goes below the minimum:
>
> [...]
> -	if (!unregister && !idev->cnf.disable_ipv6) {
> +	if (!unregister && !idev->cnf.disable_ipv6 &&
> +	    dev->mtu >= IPV6_MIN_MTU) {
>
> Regenerating the route in this case is more complexity for a case that
> nobody is hitting other than fuzzers.

No, mine does not touch MTU at all. dev->mtu stays above 1280 the whole
time. My trigger is a second addrconf_ifdown() racing the pending
addrconf_dad_work from an earlier up, both inside a single "ip link set
lo up" call (that fires both NETDEV_UP and NETDEV_CHANGE through
addrconf_notify()). The route gets deleted, the notifier gets skipped,
and the async work later runs with ifp->rt NULL.

I checked this against the source rather than assuming it: your MTU
check sits in the NETDEV_CHANGEMTU branch of addrconf_notify(), and my
reproducer never crosses that branch. So I think these are two separate
entry points into the same broken state (kept address, no route,
notifier skipped), not one bug with two descriptions of it.

Your fix looks right to me and I would support it landing as is: it
closes the MTU triggered path cleanly by gating keep_addr_on_down on
dev->mtu >= IPV6_MIN_MTU in addrconf_ifdown(). It would not close mine
though, since my race never brings dev->mtu below the minimum.

I still have a patch that regenerates the route reactively, at the
point the DAD completion work discovers ifp->rt is NULL, tested against
both my reproducer and the general shape of this race rather than just
the MTU case. I think it is worth sending regardless of whether yours
lands first, as a backstop for any other path into this state, but you
know this code far better than I do, so it is your call on order. Happy
to send mine as a follow up once yours lands, rebase mine on top of
yours, or hold off entirely if you would rather keep this scoped to
just your fix for now. Whatever is easiest for you to review.

Thanks for digging into the MTU case, the unregister argument asymmetry
in addrconf_ifdown() is what made the loopback only behavior click for
me.

Anish