> > The real 'fun' starts when you realise that a process, its real parent,
> > and a process tracing it could all be in sys_exit1() at the same time
> > (given the big_lock has been killed).
> 
> Both FreeBSD (based on Jason's comments) and Solaris probably are good 
> sources of prior art on this. What have they done?

At least one system, and not one of the above, allows the process
locks to be taken towards init (ie you can lock your parent while
holding your own lock).

To walk the sibling list, the parent must set a flag then clear the lock.
An exiting child puts itself on its "parent's ignored zombie" list
to be processed later if the flag is set.

It also has:

	 Insert our child into init's child-sibling list, while holding our
	 childs p_mutex lock.  Once we release the disinherited childs
	 p_mutex lock, it could exit.  If init were ignoring its children at
	 that time, then corruption would occur if the child exited and
	 freeproc()ed itself (though it's really hard to imagine a useful
	 version of init(1) that ignores children).  We insert the child at
	 the beginning of init's child-sibling list.  Anywhere else would be
	 disastrous, since init may be concurrently walking its
	 child-sibling list in waitid().

I'll think about whether such a flag helps.

Another interesting thing is that an exiting process switches to a per-cpu
stack (via a call) in order to exit.  Once on that stack its uarea
can safely be freed.

	David

-- 
David Laight: david@l8s.co.uk