Re: panic "wlock already held" when changing ipv6 default route

On Fri, Mar 25, 2016 at 8:14 AM, Alexander V. Chernikov
<melifaro_at_freebsd.org> wrote:
> 25.03.2016, 02:11, "Guy Yur" <guyyur_at_gmail.com>:
>> Hi,
>>
>> When changing the ipv6 default route I get a panic on wlock already held.
>> Could be related to r293424 lock changes, haven't checked an older version yet.
> Hi,
> Yes, there is a problem when the default route next hop is filled in incorrectly, so lookup fails (e.g. matches previous one).
> Will be fixed soon.
>
> Thanks for the report.
>>
>> route add -inet6 default fe80::7
>> route change -inet6 default fe80::7
>>
>> panic: rw_rlock: wlock already held for rib head lock _at_
>> /usr/src/sys/net/route.c:445
>> cpuid = 0
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0050ee01d0
>> vpanic() at vpanic+0x182/frame 0xfffffe0050ee0250
>> kassert_panic() at kassert_panic+0x126/frame 0xfffffe0050ee02c0
>> __rw_rlock() at __rw_rlock+0xe7/frame 0xfffffe0050ee0360
>> rtalloc1_fib() at rtalloc1_fib+0x86/frame 0xfffffe0050ee0420
>> ifa_ifwithroute() at ifa_ifwithroute+0x83/frame 0xfffffe0050ee0460
>> rt_getifa_fib() at rt_getifa_fib+0xe7/frame 0xfffffe0050ee0480
>> rtrequest1_fib() at rtrequest1_fib+0x59c/frame 0xfffffe0050ee0570
>> route_output() at route_output+0x653/frame 0xfffffe0050ee07c0
>> sosend_generic() at sosend_generic+0x436/frame 0xfffffe0050ee0880
>> soo_write() at soo_write+0x42/frame 0xfffffe0050ee08b0
>> dofilewrite() at dofilewrite+0x87/frame 0xfffffe0050ee0900
>> kern_writev() at kern_writev+0x68/frame 0xfffffe0050ee0950
>> sys_write() at sys_write+0x60/frame 0xfffffe0050ee09a0
>> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0050ee0ab0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0050ee0ab0
>> --- syscall (4, FreeBSD ELF64, sys_write), rip = 0x800977b7ba, rsp =
>> 0x7fffffffe2d8, rbp = 0x7fffffffeb90 ---
>> KDB: enter: panic
>> [ thread pid 644 tid 100054 ]
>> Stopped at kdb_enter+0x3b: movq $0,kdb_why
>>

Hi,

Opened bug 211602 so this won't get lost.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211602

Also happens when the gateway route was deleted so not specific
to link-local addresses.
# route add -inet6 2001:db8:0::/64 fe80::7%lo0
# route add -inet6 2001:db8:1::/64 2001:db8:0::1
# route delete -inet6 2001:db8:0::/64
# route change -inet6 2001:db8:1::/64 2001:db8:0::1

I restored RTF_RNH_LOCKED locally as a workaround so rtalloc1_fib
won't try to lock when rtrequest1_fib already took a lock before
calling rtrequest1_fib_change.

On a related note, also mentioned by Bjoern, should link-local
gateway addresses without %IF zone index be accepted?

This can be confusing when you forget the %IF and think you added
the route correctly but it is acting as a black hole.
I forgot the %IF when adding the default route and stumbled on this panic.

On OpenBSD when the gateway is missing the zone index the route is rejected.
# route add -inet6 default fe80::7
route: writing to routing socket: Network is unreachable
add net default: gateway fe80::7: Network is unreachable

Thanks,
Guy