Date: Tue, 22 May 2012 23:56:08 +0400 From: Andrey Zonov <andrey@zonov.org> To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@freebsd.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: panic with overcommit and RACCT Message-ID: <4FBBEF58.6060604@zonov.org> In-Reply-To: <09BCC731-0060-400D-8A25-4FB5268FA00D@freebsd.org> References: <4FAFEEEF.3040706@zonov.org> <20120513202920.GA18238@dft-labs.eu> <4FB177EE.7030808@zonov.org> <4FB8F055.9080700@zonov.org> <09BCC731-0060-400D-8A25-4FB5268FA00D@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/22/12 8:04 PM, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Andrey Zonov w dniu 20 maj 2012, o godz. 15:23: >> On 5/15/12 1:23 AM, Andrey Zonov wrote: >>> 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. >> >> Can anyone commit this fix? > > I've committed a slightly different fix (previous one would leak RCTL > structures) in 235787; it's also attached below. Could you please test it? Thanks, it works! > I plan to MFC it in two weeks from now. Much appreciate. > > Index: kern_racct.c > =================================================================== > --- kern_racct.c (revision 235699) > +++ kern_racct.c (working copy) > @@ -594,6 +594,9 @@ out: > PROC_UNLOCK(child); > PROC_UNLOCK(parent); > > + if (error != 0) > + racct_proc_exit(child); > + > return (error); > } > > Index: kern_fork.c > =================================================================== > --- kern_fork.c (revision 235699) > +++ kern_fork.c (working copy) > @@ -939,8 +939,8 @@ fail: > #ifdef MAC > mac_proc_destroy(newproc); > #endif > + racct_proc_exit(newproc); > fail1: > - racct_proc_exit(newproc); > if (vm2 != NULL) > vmspace_free(vm2); > uma_zfree(proc_zone, newproc); > -- Andrey Zonov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FBBEF58.6060604>