https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290201
Bug ID: 290201
Summary: Freed UMA keg (rtentry) was not empty (6 items). Lost
4 pages of memory.
Product: Base System
Version: 16.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Sometimes the system panics running network (specifically, pf) regression tests
under KASAN
Freed UMA keg (rtentry) was not empty (6 items). Lost 4 pages of memory.
panic: ASan: Invalid access, 4-byte read at 0xfffffe00e4398800,
UMAUseAfterFree(fd)
cpuid = 2
time = 1760358154
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfffffe009846f670
kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfffffe009846f7d0
vpanic() at vpanic+0x214/frame 0xfffffe009846f970
panic() at panic+0xb5/frame 0xfffffe009846fa40
kasan_report() at kasan_report+0xdf/frame 0xfffffe009846fb10
uma_zfree_arg() at uma_zfree_arg+0x1f/frame 0xfffffe009846fbb0
destroy_rtentry_epoch() at destroy_rtentry_epoch+0x17a/frame 0xfffffe009846fc70
epoch_call_task() at epoch_call_task+0x26d/frame 0xfffffe009846fd50
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x366/frame 0xfffffe009846feb0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x138/frame
0xfffffe009846fef0
fork_exit() at fork_exit+0xa3/frame 0xfffffe009846ff30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe009846ff30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 0 tid 100009 ]
Stopped at kdb_enter+0x34: movq $0,0x22b8a81(%rip)
The associated 'Freed UMA keg (rtentry) was not empty' is an additional hint of
what's going on: We're freeing an rtentry *after* we destroyed the uma zone
from which it was allocated.
This is a deferred free of the rtentry, via the (net) epoch system.
>From additional log output and experimentation I believe that the cleanup flow
for the relevant rtentry is: ip6_destroy() -> in6_purgeaddr():1400 ->
ifa_maintain_loopback_route():161 -> rib_action() -> rib_del_route().
ip6_destroy() is called from `VNET_SYSUNINIT(inet6, SI_SUB_PROTO_DOMAIN,
SI_ORDER_THIRD, ip6_destroy, NULL);`.
The destruction of the uma zone is called from vnet_rtzone_destroy(), via
rtables_destroy(), called by `VNET_SYSUNINIT(rtables_destroy,
SI_SUB_PROTO_DOMAIN, SI_ORDER_FIRST,
rtables_destroy, NULL);`.
As (VNET_)SYSUNINIT calls these functions in reverse order ip6_destroy() should
be getting called before rtables_destroy(), and rtables_destroy() explicitly
calls NET_EPOCH_CALLBACK_DRAIN() before calling rtables_destroy() this looks a
lot like epoch not working as expected (i.e. not fully draining the callbacks).
--
You are receiving this mail because:
You are the assignee for the bug.
