Subject: Re: root file system type: ffs
To: Chuck Cranor <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 09/01/1998 00:31:38
On Mon, 31 Aug 98 21:08:49 CDT
Chuck Cranor <email@example.com> wrote:
> i believe the pool allocator has uncovered a design problem in the
> process exit code path.
> looking at kern_exit.c, the final thing it does is set curproc
> to NULL and call cpu_exit. once curproc is NULL, we are no longer
> allowed to sleep. that means that we really have no business
> calling vm_map_lock() in cpu_exit() or any function it calls [because
> vm_map_lock() can sleep if the map is busy... not likely to be the
> case for the kernel map because we are single threaded right now,
> but it is best not to depend on that in the future...]
> looking at the cpu_exit() functions on various ports, they all
> seem to call uvmspace_free() and various pmap functions. i believe
> there are several calls to vm_map_lock in that general area.
> this seems bad. [maybe we should add a DIAGNOSTIC to vm_map_lock
> to check for a NULL curproc to catch these?]
> it isn't clear to me what the best way to clean this up is.
> i guess one temptation might be to push the clearing of curproc
> back later into the cpu_exit function...?
Setting curproc == NULL later seems OK at first, and I started down that
Note that the process is already SZOMB at this point. There are two
(1) Clock interrupt might deref already freed structure (can
deal with this by also testing for SZOMB in addition for
(2) Can't wakeup a SZOMB process.
Charles Hannum mentioned to me some "zombifier daemon" diffs he'd worked
out once, that make the exit code a lot less evil. He no longer has them,
but we have discussed how it worked, and I think I can implement it tomorrow.
It actually make more code MI!
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 650 940 5942