On Sunday, 2 April 2000 at 17:23:49 -0700, Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [000402 17:04] wrote:
>>
>> :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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
>> :"I have the heart of a child; I keep it in a jar on my desk."
>>
>> What happens when the parent process exits and the system must
>> reassign the parent to process 1? Now think about what happens
>> when it occurs on one cpu while another is trying to access the
>> ppid.
>>
>> cpu#1: cpu#2:
>>
>> read p->p_pptr
>> indirect through to get ppid
>> (stalls on a cache miss plus,
>> due to heavy DMA, stalls on main memory)
>> parent process finishes
>> exiting, replaces p_pptr
>> of children, releases
>> struct proc.
>>
>> struct proc is reused,
>> pid is reallocated
>> read completes, wrong ppid is returned
>> (neither the original ppid nor ppid 1
>> is returned).
>>
>> In an SMP system you have to assume the worst case, and the worst case
>> is that a cpu can stall INDEFINITELY between instructions.
>
> Good call.
>
> Ugh, I should think about this more, but i'll just grasp at straws
> and suggest that p_pptr is set to volatile variable, and we re-read
> it after we snarf the pid from the pointer and make sure it hasn't
> changed out from under us.
>
> Either that or store it in the child's proc struct as well.
This seems the obvious solution.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
