Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Apr 2018 17:17:31 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 222027] panic on non-zero RACCT destroy
Message-ID:  <bug-222027-227-LfdUKPeTR6@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-222027-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-222027-227@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=3D222027

--- Comment #7 from Andriy Gapon <avg@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 report=
ed
so far in that bug and in this bug.

I suspect that the problem could be with this pattern used in many places w=
here
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 t=
hat
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 s=
ome
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 pre=
vent
the problem, but there must be a good reason why that function requires tha=
t it
is not called with under the lock...
So, not sure...

--=20
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-222027-227-LfdUKPeTR6>