Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Apr 2000 16:47:00 -0700
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c
Message-ID:  <20000402164700.R21029@fw.wintelcom.net>
In-Reply-To: <200004022312.QAA51299@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, Apr 02, 2000 at 04:12:18PM -0700
References:  <200004021752.KAA13175@freefall.freebsd.org> <20000402163552.P21029@fw.wintelcom.net> <200004022312.QAA51299@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [000402 16:37] wrote:
> 
> :Along with snagging the "easy ones" for MP safeness, shouldn't getpid
> :be MP safe?  The struct proc is allocated from the proc_zone, and
> :afaik zalloc allows for stable storage meaning it's safe to dereference
> :the ppid pointer once the entire struct proc is populated, which needs
> :to happen before the process can even call getpid().
> :
> :phk seems to agree.
> :
> :-- 
> :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> :"I have the heart of a child; I keep it in a jar on my desk."
> 
>     The problem is that getpid() also extracts the ppid (look at
>     the syscall code), which is not MP safe.

I did look at the code, struct proc is allocated from a zone,
meaning it won't "go away" once allocated, there's no danger in
dereferencing p_pptr, I don't get it.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000402164700.R21029>