On Wed, Jun 08, 2005 at 12:12:52AM +0100, David Laight wrote:
> 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.

Unmapped is a real problem; without this, you could still 
	pp = p->parent;
	do {
		qq = pp;
		ppid = pp->pid;
		pp = p->parent;
	} while (pp != qq);

Regards,
	-is

-- 
seal your e-mail: http://www.gnupg.org/