When I create / remove a jail with VNET epair interfaces with the firewall disabled all is ok. If I enable the Firewall I got a "Freed UMA keg (pf table entries) was not empty (-8 items). Lost -2 pages of memory." Packet filter loose tables values (pfctl -t WHITELIST -T show => empty) if I disable PF: pfctl -d => ok if I réenable PF: pfctl -e => kernel panic
This problem is with PF out of the jail.
I have the same issue on FreeBSD 11.0-RELEASE-p7 #26 r312891 Issue is still occurring permanently.
(In reply to pg from comment #2) Still for "pf table entries"? And still a negative amount (is it always -2) of pages?
still a negative amount. For example: # grep UMA /var/log/messages Jan 27 22:20:53 fido706 kernel: Freed UMA keg (pf table entries) was not empty (70 items). Lost -1 pages of memory. Jan 28 01:40:46 fido706 kernel: Freed UMA keg (pf table entries) was not empty (20 items). Lost -3 pages of memory. After that PF lost part of rules.
I ran into this today (11.0-RELEASE). pf is enabled on host, not inside jail. When destroying the jail I got message on console: Freed UMA keg (pf table entries) was not empty (20 items). Lost -1 pages of memory. If I repeat creation and removal of jail several times the system panics. Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff80ad5ef1 stack pointer = 0x28:0xfffffe012145e5a0 frame pointer = 0x28:0xfffffe012145e640 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 3431 (ifconfig) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff80b25ac7 at kdb_backtrace+0x67 #1 0xffffffff80ada972 at vpanic+0x182 #2 0xffffffff80ada7e3 at panic+0x43 #3 0xffffffff80fb9d51 at trap_fatal+0x351 #4 0xffffffff80fb99e8 at trap+0x768 #5 0xffffffff80f9c861 at calltrap+0x8 #6 0xffffffff82651f39 at pfi_instance_add+0x39 #7 0xffffffff826516ff at pfi_kif_update+0xff #8 0xffffffff82650c08 at pfi_change_group_event+0x88 #9 0xffffffff80bdc825 at if_addgroup+0x9b5 #10 0xffffffff80bda0d7 at if_attach_internal+0xc7 #11 0xffffffff80be65de at ether_ifattach+0x1e #12 0xffffffff8267d85c at epair_clone_create+0x30c #13 0xffffffff80be3bea at if_clone_createif+0x4a #14 0xffffffff80bde76d at ifioctl+0x22d #15 0xffffffff80b43504 at kern_ioctl+0x2d4 #16 0xffffffff80b431c1 at sys_ioctl+0x171 #17 0xffffffff80fba6ae at amd64_syscall+0x4ce
This issue (leaks memory) occurred when epair freed up from Jail.
Yes, the message "Freed UMA keg (pf table entries) was not empty (20 items)" occurs consistently when jail goes down, apparently when epair is being freed. But it seems that panic message after that is not always exactly same. But system panics always, usually during next jail up-down attempt.
I tested this on -current of today. Performing jail -c testvnet1 jail -r testvnet1 jail -c testvnet1 jail -r testvnet1 always triggers same panic: panic: Assertion keg == slab->us_keg failed at ../../../vm/uma_core.c:2797 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe005119a1b0 vpanic() at vpanic+0x186/frame 0xfffffe005119a230 kassert_panic() at kassert_panic+0x126/frame 0xfffffe005119a2a0 zone_release() at zone_release+0x93/frame 0xfffffe005119a300 zone_dtor() at zone_dtor+0x1a7/frame 0xfffffe005119a350 zone_free_item() at zone_free_item+0x58/frame 0xfffffe005119a380 uma_zdestroy() at uma_zdestroy+0x36/frame 0xfffffe005119a3a0 pfr_cleanup() at pfr_cleanup+0x26/frame 0xfffffe005119a3c0 vnet_pf_uninit() at vnet_pf_uninit+0x4c0/frame 0xfffffe005119a870 vnet_destroy() at vnet_destroy+0x12c/frame 0xfffffe005119a8a0 prison_deref() at prison_deref+0x29d/frame 0xfffffe005119a8e0 sys_jail_remove() at sys_jail_remove+0x1f2/frame 0xfffffe005119a930 amd64_syscall() at amd64_syscall+0x2f9/frame 0xfffffe005119aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe005119aab0 --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x800ea383a, rsp = 0x7fffffffe998, rbp = 0x7fffffffea10 --- This occurs only if pf *with table* is enabled on *host*, for example this pf.conf is suitable for testing: table <home> persist { 192.168.0.0/16 } set skip on lo0 pass all
Created attachment 181972 [details] Fix to add some pf data structures to VNET When stopping a jail, the unload traverses over the allocated table entries using the list that belongs to the default vnet. This patch will bring those data structures under VNET, so they are private to a VNET.
Fixed commited in r317400.