On 5/14/12 12:29 AM, Mateusz Guzik wrote:
On Sun, May 13, 2012 at 09:27:11PM +0400, Andrey Zonov wrote:
Hi,
I've got a repeatable panic on latest 9.0-STABLE and HEAD with
turned on overcommit (vm.overcommit=1) and RACCT.
kgdb trace on today's HEAD:
#10 0xffffffff80bc3513 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#11 0xffffffff808aab71 in racct_set_locked (p=0xfffffe0005d684a0,
resource=0,
amount=2680) at /usr/src/sys/kern/kern_racct.c:372
#12 0xffffffff808ab645 in racct_proc_exit (p=0xfffffe0005d684a0)
at /usr/src/sys/kern/kern_racct.c:615
#13 0xffffffff80880d69 in fork1 (td=0xfffffe0005b2c460, flags=20, pages=4,
procp=0xffffff811a36bb00, procdescp=Variable "procdescp" is not
available.
) at /usr/src/sys/kern/kern_fork.c:943
#14 0xffffffff80882362 in sys_fork (td=0xfffffe0005b2c460,
uap=Variable "uap" is not available.
)
at /usr/src/sys/kern/kern_fork.c:110
#15 0xffffffff80bd7a89 in amd64_syscall (td=0xfffffe0005b2c460, traced=0)
at subr_syscall.c:135
#16 0xffffffff80bc37f7 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#17 0x00000008024729fc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Unread portion of the kernel message buffer:
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex racct lock (racct lock) r = 0
(0xffffffff8128a7c0) locked @ /usr/src/sys/kern/kern_racct.c:614
exclusive sleep mutex process lock (process lock) r = 0
(0xfffffe0005d68598) locked @ /usr/src/sys/kern/kern_racct.c:603
It looks like racct_proc_exit can be called for processes without
properly initialized racct structure, which in turn results in this
panic.
Can you please test this patch:
http://student.agh.edu.pl/~mjguzik/patches/racct-fork.patch
?
I was unable to reproduce panic you describe, so it was tested only by
manually injecting error. Nevertheless I think you should try it. :)
Thanks, your patch fixes the panic.
How to repeat:
1. add options RACCT and options RCTL to kernel config, rebuild and
install kernel, reboot
2. set sysctl vm.overcommit=1
3. run as none root something that eats memory (I just run malloc()
until it returns NULL)
4. swapoff -a
5. panic after sometime
With patch applied instead of panic I got: "fork: Cannot allocate
memory". Looks like a bug in overcommit code.
--
Andrey Zonov
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
