Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 May 2016 23:03:40 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize
Message-ID:  <bug-209475-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209475

            Bug ID: 209475
           Summary: pf didn't check if enough free RAM for
                    net.pf.states_hashsize
           Product: Base System
           Version: 10.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: olivier@freebsd.org

I'm playing with benching some pf limits and I've found an easy way to block
kldload pf.ko:

We just need to set a net.pf.states_hashsize value too big for the system
available RAM.
This table is a static table with each entry consuming about 80 bytes of RA=
M.
Manual page ask to use power of 2 values, then I've try this big value on my
8GB RAM server:

echo 'net.pf.states_hashsize=3D"67108864"' >>/boot/loader.conf
Notice that 67108864 * 80 should be close to 5 GB of RAM reserved.

Then when I run a "service pf onestart", this start a "kldload pf.ko", but
kldload stuck and never give the console back on my 8GB RAM server (we can
escape with a Ctrl+Z).
But if pf is enabled in rc.conf, this prevent the system to correctly boot.

A Ctrl+D give this kind of information:

load: 0.02  cmd: kldload 1166 [kmem arena] 180.93r 0.00u 0.00s 0% 1700k
load: 0.02  cmd: kldload 1166 [kmem arena] 182.69r 0.00u 0.00s 0% 1700k
load: 0.02  cmd: kldload 1166 [kmem arena] 182.96r 0.00u 0.00s 0% 1700k
load: 0.02  cmd: kldload 1166 [kmem arena] 183.50r 0.00u 0.00s 0% 1700k

During this status, issuing command "pfctl" will crash the system:

Fatal trap 12: page fault while in kernel mode
cpuid =3D 0; apic id =3D 00
fault virtual address   =3D 0x0
fault code              =3D supervisor read data, page not present
instruction pointer     =3D 0x20:0xffffffff81a311b4
stack pointer           =3D 0x28:0xfffffe00003aba60
frame pointer           =3D 0x28:0xfffffe00003ac7f0
code segment            =3D base 0x0, limit 0xfffff, type 0x1b
                        =3D DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        =3D interrupt enabled, resume, IOPL =3D 0
current process         =3D 1869 (pfctl)
trap number             =3D 12
panic: page fault
cpuid =3D 0
KDB: stack backtrace:
#0 0xffffffff807f5c70 at kdb_backtrace+0x60
#1 0xffffffff807bc276 at vpanic+0x126
#2 0xffffffff807bc143 at panic+0x43
#3 0xffffffff80b4874b at trap_fatal+0x36b
#4 0xffffffff80b48a4d at trap_pfault+0x2ed
#5 0xffffffff80b480ca at trap+0x47a
#6 0xffffffff80b2e2c2 at calltrap+0x8
#7 0xffffffff80715779 at devfs_ioctl_f+0x139
#8 0xffffffff8081013f at kern_ioctl+0x20f
#9 0xffffffff8080fe8c at sys_ioctl+0x15c
#10 0xffffffff80b490b8 at amd64_syscall+0x3a8
#11 0xffffffff80b2e5ab at Xfast_syscall+0xfb
Uptime: 1m44s

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209475-8>