Date: Mon, 13 Oct 2025 12:30:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 290201] Freed UMA keg (rtentry) was not empty (6 items). Lost 4 pages of memory. Message-ID: <bug-290201-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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: bugs@FreeBSD.org Reporter: kp@freebsd.org 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-290201-227>