I'm using 11.1-STABLE (r326255) and this issue occurs from time to time
(usually the server crashes every day, or every few days.)
I believe the problem lays in a mechanism of memory freeing for the Jail subsystem.
I'm running few jails with vnet/vimage + PF filter in each.
Basically each jail is a small virtual router with simple nat (lan0->wan0 natting).
Could you please tell me what other info should I collect and attach to this bug?
FreeBSD hestia.ithouse.org.ua 11.1-STABLE FreeBSD 11.1-STABLE #9 r326255: Mon Nov 27 17:42:17 EET 2017 firstname.lastname@example.org:/usr/obj/usr/src/sys/HESTIA amd64
panic: page fault
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 14
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80ab58dc
stack pointer = 0x28:0xfffffe0b59c5eb00
frame pointer = 0x28:0xfffffe0b59c5eb00
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 = 17 (pf purge)
trap number = 12
panic: page fault
cpuid = 4
KDB: stack backtrace:
#0 0xffffffff80abb987 at kdb_backtrace+0x67
#1 0xffffffff80a779f6 at vpanic+0x186
#2 0xffffffff80a77863 at panic+0x43
#3 0xffffffff80f4562d at trap_fatal+0x34d
#4 0xffffffff80f45689 at trap_pfault+0x49
#5 0xffffffff80f44eda at trap+0x29a
#6 0xffffffff80f28a71 at calltrap+0x8
#7 0xffffffff80cebde5 at pf_state_expires+0x75
#8 0xffffffff80ceb6b5 at pf_purge_expired_states+0xf5
#9 0xffffffff80ceb574 at pf_purge_thread+0x134
#10 0xffffffff80a3ad85 at fork_exit+0x85
#11 0xffffffff80f2905e at fork_trampoline+0xe
VNET is not supported on 11, and 11.1 went out of support back in September of last year as well.
I recognize the backtrace though, and it's fixed in 12.0. See #219251
*** This bug has been marked as a duplicate of bug 219251 ***