Confusion about process states and invariants

[Tim Robbins]

On Sun, Jun 27, 2004 at 03:13:18PM +0200, Pawel Jakub Dawidek wrote:
> On Sat, Jun 26, 2004 at 12:38:43PM -0400, Robert Watson wrote:
> +> Over the last two weeks, I've seen several reports of panics relating to
> +> code making incorrect assumptions about process state, generally relating
> +> to the "p_ucred" pointer in new and dying processes.  In particular, a
> +> number of pieces of code assume that if a process is reachable by the all
> +> process list (or other process lists), p_ucred will be valid and non-NULL
> +> if the process lock is held on the process.  This results in possible NULL
> +> pointer dereferences in the PRS_NEW state, and also during the tear-down
> +> in kern_wait().  At first glance, the easy answer would appear to be
> +> "check for p_ucred to be NULL", but I'm actually of the opinion that I'd
> +> prefer we have the non-NULL p_ucred invariant actually hold true.  This
> +> would permit security checks to be performed properly during those
> +> windows.  I'm not very familiar with our process state and locking, but if
> +> someone with a more qualified background in that area could comment on the
> +> current issue, that would be useful.
> 
> Couldn't we move crhold() for p_ucred before it is placed on allproc list?

p_ucred is just the tip of the iceberg -- a lot of code assumes that
processes on allproc are fully set up. We should either delay putting the
process onto allproc until it's correctly initialized (taking care to avoid
races in PID allocation), or not drop the allproc sx until initialization
is done.


Tim