kern/161552: kernel panic with RCTL option: racct_alloc_resource: usage < 0

[Nikos Vassiliadis]

>Number:         161552
>Category:       kern
>Synopsis:       kernel panic with RCTL option: racct_alloc_resource: usage < 0
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 13 18:00:21 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Nikos Vassiliadis
>Release:        FreeBSD 10.0-CURRENT
>Organization:
>Environment:
FreeBSD lab.local 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r226271M: Thu Oct 13 19:29:17 EEST 2011     root at lab.local:/usr/obj/usr/src/sys/RCTLLAB  i386
>Description:
A kernel with option RCTL panics after some time.
amount in frame #11 seems very big, should it be signed?

Backtrace:
Unread portion of the kernel message buffer:
panic: racct_alloc_resource: usage < 0
cpuid = 0
KDB: enter: panic
Physical memory: 1003 MB
Dumping 65 MB: 50 34 18 2

#0  doadump (textdump=-995676160) at pcpu.h:244
244     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=-995676160) at pcpu.h:244
#1  0xc04f1b79 in db_fncall (dummy1=1, dummy2=0, dummy3=-1054062208,
    dummy4=0xd90caa40 "") at /usr/src/sys/ddb/db_command.c:572
#2  0xc04f1f71 in db_command (last_cmdp=0xc10e24bc, cmd_table=0x0, dopager=1)
    at /usr/src/sys/ddb/db_command.c:448
#3  0xc04f20ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:501
#4  0xc04f40bd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
#5  0xc0a56743 in kdb_trap (type=3, code=0, tf=0xd90cabf0)
    at /usr/src/sys/kern/subr_kdb.c:625
#6  0xc0da70eb in trap (frame=0xd90cabf0) at /usr/src/sys/i386/i386/trap.c:719
#7  0xc0d8fa8c in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#8  0xc0a5654a in kdb_enter (why=0xc0f68ea8 "panic", msg=0xc0f68ea8 "panic")
    at cpufunc.h:71
#9  0xc0a21634 in panic (fmt=0xc0f67d32 "racct_alloc_resource: usage < 0")
    at /usr/src/sys/kern/kern_shutdown.c:599
#10 0xc0a184f2 in racct_alloc_resource (racct=0xc49a947c, resource=19,
    amount=18446744069415584193) at /usr/src/sys/kern/kern_racct.c:258
#11 0xc0a1899f in racct_set_locked (p=0xc4dd02c4, resource=19,
    amount=18446744071563033602) at /usr/src/sys/kern/kern_racct.c:398
#12 0xc0a18bf3 in racctd () at /usr/src/sys/kern/kern_racct.c:739
#13 0xc09f04c8 in fork_exit (callout=0xc0a18a10 <racctd>, arg=0x0,
    frame=0xd90cad28) at /usr/src/sys/kern/kern_fork.c:995
#14 0xc0d8fb04 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275
(kgdb)



>How-To-Repeat:
I have not find what triggers the panic, but it always panics after an hour of uptime or so. The machine is a virtualbox VM with 2 CPUs. My kernel's cf:
include   GENERIC
ident     RCTLLAB

options   VIMAGE
options   VNET_DEBUG
options   IPSEC
device    crypto

options   IPFIREWALL
options   IPFIREWALL_DEFAULT_TO_ACCEPT
options   IPFIREWALL_FORWARD

options RACCT
options RCTL

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: