Bug 253061 - sys/net/if_vlan:qinq_deep test triggers "UNR: free_unr(3735929054) out of range" panic
Summary: sys/net/if_vlan:qinq_deep test triggers "UNR: free_unr(3735929054) out of ran...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexander V. Chernikov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-28 12:57 UTC by Alex Richardson
Modified: 2021-01-30 17:50 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson freebsd_committer freebsd_triage 2021-01-28 12:57:10 UTC 
Running `cd /usr/tests && kyua test` on a single-core QEMU amd64 I get the following panic:

sys/net/if_vlan:qinq_deep ->  Jan 28 11:28:13 freebsd-amd64 kernel: ng_ether_ifnet_arrival_event: can't re-name node epair1a
Jan 28 11:28:13 freebsd-amd64 kernel: ng_ether_ifnet_arrival_event: can't re-name node epair1b
Jan 28 11:28:13 freebsd-amd64 kernel: ng_ether_ifnet_arrival_event: can't re-name node epair1a
panic: UNR: free_unr(3735929054) out of range [0...32767]
cpuid = 0
time = 1611833293
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0093bdb970
vpanic() at vpanic+0x188/frame 0xfffffe0093bdb9c0
panic() at panic+0x43/frame 0xfffffe0093bdba20
free_unr() at free_unr+0x38d/frame 0xfffffe0093bdba60
ifc_free_unit() at ifc_free_unit+0x16/frame 0xfffffe0093bdba90
vlan_clone_destroy() at vlan_clone_destroy+0xaf/frame 0xfffffe0093bdbac0
if_clone_destroyif() at if_clone_destroyif+0x185/frame 0xfffffe0093bdbb10
if_clone_detach() at if_clone_detach+0xc8/frame 0xfffffe0093bdbb40
vnet_destroy() at vnet_destroy+0x140/frame 0xfffffe0093bdbb70
prison_deref() at prison_deref+0x2fe/frame 0xfffffe0093bdbbb0
sys_jail_remove() at sys_jail_remove+0x21a/frame 0xfffffe0093bdbc00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0093bdbd30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0093bdbd30
--- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x8003c9b2a, rsp = 0x7fffffffe7f8, rbp = 0x7fffffffe880 ---
KDB: enter: panic
[ thread pid 8883 tid 103789 ]
Stopped at      kdb_enter+0x37: movq    $0,0x10a150e(%rip)
db>
Comment 1 Alexander V. Chernikov freebsd_committer freebsd_triage 2021-01-29 21:53:44 UTC 
Does it always panic?
Wasn't able to reproduce by running the actual test ~100 times on my VM.

53729367d388e4a6d0ff9be9995bcd4957e9c114 will probably fix it, but I'm not sure if if fixes the root cause.
Comment 2 Alex Richardson freebsd_committer freebsd_triage 2021-01-29 23:54:34 UTC 
It happened to me twice so far. Maybe running on single-CPU QEMU makes it more reproducible?
Comment 3 Alex Richardson freebsd_committer freebsd_triage 2021-01-29 23:56:16 UTC 
Thanks for the fix! I'll test again on Monday.
Comment 4 Alex Richardson freebsd_committer freebsd_triage 2021-01-30 17:50:51 UTC 
It seems like this is fixed: I tested commit 7587d9823a8257b9a2d5b2e58c707026061058c6 which includes 53729367d388e4a6d0ff9be9995bcd4957e9c114.
Thanks for the quick fix!