On Thu, Oct 01, 2026 at 06:46:29PM +0300, Ido Schimmel wrote:
> On Wed, Sep 30, 2026 at 11:22:28AM -0400, [email protected] wrote:
[...]
> > # ip link set dev lo down
> > # ip -6 route add 2001:db8::/32 dev lo
> > Error: Nexthop device is not up.
>
> Consistent with IPv4 and expected:
[...]
> I don't understand what motivated this series.
Thanks for the review, and sorry that the motivation was not clear.
I found this while comparing the behavior of different kernel versions.
It does not come from a user report and I am not aware of anything that
depends on the old behavior. These commands succeeded before
21ec92774d15, and its changelog describes the
"ip -6 route add 2001:db8::/32 dev lo" case as unchanged apart from the
unused nhc_pcpu_rth_output allocation. As the commit also went to the
stable trees, I took the new errors for an unintended side effect and
tried to restore the old results.
I agree that the current behavior is consistent with IPv4. The syzbot ci
report on this series also shows that the old behavior was wrong for
multipath routes. With patch 1 applied, as before 21ec92774d15,
# ip -6 route add 2001:db8:100::/64 \
nexthop via fe80::1 dev eth1 nexthop via fe80::1 dev lo
is accepted and installs two separate routes: the loopback nexthop
becomes a reject route that does not qualify for ECMP, while
ip6_route_multipath_add() still notifies the first route with nhn - 1
siblings. With a netdevsim device, I can reproduce the WARN_ON_ONCE()
in nsim_fib6_event_init() with this command on the patched kernel, and
it is followed by a NULL pointer dereference in nsim_fib_event_work().
The current code rejects the loopback nexthop instead.
So please drop this series. Sorry for the noise.
