Subject: Re: locking p_children, p_sibling and p_pptr
From: David Laight <firstname.lastname@example.org>
Date: 11/07/2003 22:04:10
> > 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 Laight: email@example.com