On Tue, Jun 07, 2005 at 03:53:40PM -0400, Nathan J. Williams wrote:
> Ignatios Souvatzis <is@NetBSD.org> writes:
> 
> > Why? Maybe I'm missing something, but what keeps the parent from dying
> > after the syscall returns in the child, but before the child uses the
> > information? If nothing, as I think, what changes when the parent dies
> > using a different cpu? Oh wait, getppid & friends have to pull the ppid
> > value out of the parent's nose... I wonder whether it would be better to
> > cache the ppid value in the children and update it when the parent dies.
> 
> Perhaps I'm being too pessimistic, but I don't like to assume that any
> variable updates are atomic. It's okay if the result is the old parent
> or the new parent, but it's not okay to get (say) the top bits from
> the old parent and the bottom bits from the new parent.

More likely you need;
    return curproc->parent->pid;
the parent could exit, and it's proc structure be freed (and maybe reused)
between when you read curproc->parent and dereference parent->pid.
In which case you are reading random (possibly unmapped) kernel memory.

Also be aware that the apparant fine-grain locking of the parent-child
heirarchy in kern_proc.c is somewhat broken - and difficult to fix
while gdb does re-parenting.  A global lock for all processes could
be implemented.

	David

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