Date: Mon, 30 Jan 2017 13:14:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 210315] panic: destroying non-empty racct: 2113536 allocated for resource 4 Message-ID: <bug-210315-8-0LqegTbCs1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-210315-8@https.bugs.freebsd.org/bugzilla/> References: <bug-210315-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210315 --- Comment #11 from Andriy Gapon <avg@FreeBSD.org> --- (In reply to Edward Tomasz Napierala from comment #8) Yes, that must be true. It is impossible to get that problem for the process racct. I have one hypothesis now. Consider the following sequence of events: 0. the vm daemon gets a reference on a vm space of a process 1. the vm daemon invokes the first racct_set(p, RACCT_RSS, rsize) call for the process 2. the process exits and vmspace_exit() is called for the the vm space 3. the vm daemon calls racct_set(p, RACCT_RSS, rsize) within if (rsize > ravailable) block 4. the vm daemon releases the vm space I think that in this scenario we would do the following: 1. set RACCT_RSS of the process to X 2. set RACCT_RSS of the process to zero 3. set RACCT_RSS of the process (now a zombie) to Y I think that that last call would screw up the accounting for raccts that include the process. In fact, it also screws up the accounting for the process itself, but that is masked by the code in racct_proc_exit() that sets to zero all reclaimable resources. Ah, and because of what racct_proc_exit() does, we have this: 4. set RACCT_RSS of the process (now a zombie) to zero So, it looks like only the jail accounting is affected and we see it only in the window between exit1() dropping the reference to the jail and proc_reap(). So, to recap, the full sequence: 0. the vm daemon gets a reference on a vm space of a jailed process 1. the vm daemon invokes the first racct_set(p, RACCT_RSS, rsize) call for the process 2. the process exits and vmspace_exit() is called for the the vm space 3. the vm daemon calls racct_set(p, RACCT_RSS, rsize) within if (rsize > ravailable) block 4. the vm daemon releases the vm space 5. the process drops its reference to the jail 6. the jail gets destroyed <-- here we hit the problem I think that the above could explain the panics that I saw. Not sure if the Larry's panic can be fit into the hypothesis. -- 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-210315-8-0LqegTbCs1>