Bug 223959 - [pf] page fault in pf_purge_expired_states+0xf5 -> pf_state_expires+0x75 on 11.1-STABLE r326255
Summary: [pf] page fault in pf_purge_expired_states+0xf5 -> pf_state_expires+0x75 on 1...
Status: Closed DUPLICATE of bug 219251
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2017-11-29 07:14 UTC by Nikita Olenets
Modified: 2022-10-12 00:49 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Olenets 2017-11-29 07:14:44 UTC
Hello,

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?

Appreciated.


FreeBSD hestia.ithouse.org.ua 11.1-STABLE FreeBSD 11.1-STABLE #9 r326255: Mon Nov 27 17:42:17 EET 2017     root@hestia.ithouse.org.ua:/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
Uptime: 1d11h53m3s
Comment 1 Kristof Provost freebsd_committer freebsd_triage 2019-02-12 14:46:57 UTC
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
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-02-13 02:17:53 UTC

*** This bug has been marked as a duplicate of bug 219251 ***