kern/50216: kernel panic on 5.0-current when use ipfw2 with dynamic rules

Kang Liu liukang at bjpu.edu.cn
Tue Sep 30 09:50:41 PDT 2003


I reproduced it on the latest 5.1current.

Here is the backtrace:
#####
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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 "i386-undermydesk-freebsd"...
panic: Most recently used by cred

panic messages:
---
panic: Most recently used by cred

Stack backtrace:

syncing disks, buffers remaining... 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 628 
giving up on 520 buffers
Uptime: 16m0s
Dumping 255 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /usr/obj/usr/src/sys/IPFW/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for /usr/obj/usr/src/sys/IPFW/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/daemon_saver.ko...done.
Loaded symbols for /boot/kernel/daemon_saver.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240		dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc01a0221 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc01a05b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc02817f7 in mtrash_ctor (mem=0xc29f8a80, size=0, arg=0x0)
    at /usr/src/sys/vm/uma_dbg.c:137
#4  0xc028002e in uma_zalloc_arg (zone=0xc083ab40, udata=0x0, flags=257)
    at /usr/src/sys/vm/uma_core.c:1413
#5  0xc0194a23 in malloc (size=3229854528, type=0xc03020c0, flags=257)
    at /usr/src/sys/vm/uma.h:234
#6  0xc021e03f in add_dyn_rule (id=0xcd7bfc90, dyn_type=39 '\'', 
    rule=0xc2815e00) at /usr/src/sys/netinet/ip_fw2.c:976
#7  0xc021e43e in install_state (rule=0xc28f3a80, cmd=0xc28f3ac0, 
    args=0xcd7bfc70) at /usr/src/sys/netinet/ip_fw2.c:1140
#8  0xc021f4dc in ipfw_chk (args=0xcd7bfc70)
    at /usr/src/sys/netinet/ip_fw2.c:1942
#9  0xc0221dd7 in ip_input (m=0xc0ed9800)
    at /usr/src/sys/netinet/ip_input.c:489
#10 0xc0211a82 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:236
#11 0xc018c762 in ithread_loop (arg=0xc0ebec80)
    at /usr/src/sys/kern/kern_intr.c:534
#12 0xc018b76f in fork_exit (callout=0xc018c5e0 <ithread_loop>, arg=0x0, 
    frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
(kgdb) 

#####
Here is my full ipfw rule set script:
# cat ./ipfwpanic.sh 
dumpon -v /dev/ad0s1b
/sbin/ipfw add allow tcp from any to any established
/sbin/ipfw add allow ip from a.b.c.0 to a.b.c.d
/sbin/ipfw add allow tcp from any to a.b.c.d 80 limit src-addr 20 setup
/sbin/ipfw add allow ip from a.b.c.d to any

And I added "IPFIREWALL_DEFAULT_TO_ACCEPT" into kernel configure file.

#####
Here is my test script. I installed an apache on that machine, and use ab to connect 80 port.
cat panicstart.sh 
#!/bin/sh
number=0
while (test $number -lt 10000)
do
echo "$number"
ab -c 100 http://a.b.c.d/
number=`expr $number + 1`
done

#####
This problem can be reproduced on both MP and UP machine.
I've tested it on a dell poweredge2650(with 2 P4xeon, HTT enabled/disabled) and a DIY PC(1 PIII CPU).
The backtrace I post above is produced on PC(1CPU).



More information about the freebsd-hackers mailing list