Bug 203822
| Summary: | [panic] _mtx_lock_sleep: recursed on non-recursive mutex rtentry | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Allan Jude <allanjude> | ||||
| Component: | kern | Assignee: | Alexander V. Chernikov <melifaro> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | ||||||
| Priority: | --- | ||||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
This appears to have been a mistake on my part I assigned the IP address x.x.x.38/27 then tried to change the default gateway to x.x.x.1 which is outside the directly connected subnet. My subnet mask should have been /26 However, a panic is not the expected result reproduction case: ifconfig igb0 172.21.0.100/24 route add default 172.21.0.1 route change default 172.21.1.1 panic. So, what is happening here: We lock existing rte (while handling RTM_CHANGE) and try to set new gateway. If gateway is not directly reachable (e.g. likely if there was an error in user input), than rt_getifa_fib() logic which is responsible for setting valid rti_ifp / rti_ifa fails to find and local address/prefix matching the gateway. As a result, ifa_ifwithroute() is called and very likely it will find rte for the default route, tries to lock it and .. The bug was introduced in r264986 - we unlocked rte / radix before attempting to guess gw. Working on a fix.. Was a fix for this even developed and committed? Was fixed in r319895. |
Created attachment 162121 [details] Image of panic/backtrace panic: _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /usr/src/sys/net/route.c:423