[Bug 222027] panic on non-zero RACCT destroy

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222027

--- Comment #7 from Andriy Gapon <avg at FreeBSD.org> ---

I think that my "fix" for bug 210315 was not a real fix.
I have another theory now which, if it holds, may explain all panics reported
so far in that bug and in this bug.

I suspect that the problem could be with this pattern used in many places where
process credentials change:

  proc_set_cred(p, newcred);
  PROC_UNLOCK(p);
  racct_proc_ucred_changed(p, oldcred, newcred);

You can see this in do_jail_attach() as well as in sys_setloginclass(),
sys_setuid() and alike.

Now, let's compare this to how RACCT_RSS is updated by vm_daemon():
  PROC_LOCK(p)
  racct_set(p, RACCT_RSS, rsize);
  PROC_UNLOCK(p);

This happens concurrently to jail_attach or setuid, etc, so it's possible that
once in a while this update will happen while the process has already been
assigned the newcred, but before racct_proc_ucred_changed() is called.  In this
case the new value would be applied to the process and its _new_ credentials
will be adjusted.  But when racct_proc_ucred_changed() is called we will
transfer the process's resource from oldcred to newcred.  So, essentially we
will removed more than needed (provided the delta was positive) from oldcred
and add more than needed to newcred.

I think that the theory explains the panic in comment #6 where a jail got some
extra RACCT_RSS.  It also seems to explain bug# 210315, comment #2 when an
underflow happened in the global space (prison0) during shutdown.

I think that doing racct_proc_ucred_changed() under the proc lock would prevent
the problem, but there must be a good reason why that function requires that it
is not called with under the lock...
So, not sure...

-- 
You are receiving this mail because:
You are the assignee for the bug.