proc_destroy() refcnting issues dealt with
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 1 Mar 2011 22:11:46 +0000 (14:11 -0800)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:35:59 +0000 (17:35 -0700)
commit63e1a99597f84ff6867693aecd1c3a723763fb14
tree1e46df9746327b1bf34ea66685a635a8e54670a7
parent9721abd6a931c4267a68b7944cf6b1c60a1dfa16
proc_destroy() refcnting issues dealt with

proc_destroy() needs to have an edible reference, which it did not have
from __do_mmap().  Incidentally, we just don't call it from there
anymore, but there were a few other unlikely errors that would be
problems.

For now, all code using a struct proc * needs to know where it got the
refcount from.  Code in the syscall path (and mm.c) usually is
'borrowing' the ref from current, and is not able to be passed without
incref to certain functions.  Also note that you can't incref too much,
since functions like proc_destroy() assume they are taking your
"working" reference (i.e., the one you passed to the function) that
should be refcnt'd exactly once.

As this is the most likely way to fuck up ref counting with processes,
if you see something odd with refcnts (kref assertions, env_cr3 != rcr3,
etc), look in places that involve these "might-not-return" functions.
kern/arch/i686/cpuinfo.c
kern/arch/i686/trap.c
kern/arch/sparc/trap.c
kern/src/mm.c
kern/src/syscall.c
kern/src/umem.c