On 21-May-01 Matt Dillon wrote:
>:On 21-May-01 Brian F. Feldman wrote:
>:> There's a certain issue that when several processes sharing a vmspace are
>:> exiting at the same time, there is a race condition such that the shared
>:> memory is going to be lost because the check for vm->vm_refcnt being the
>:> check for the last decrement happening before the last decrement is
>:> actually performed, allowing for the possibility of Giant being dropped
>:> (duh, during flushing of dirty pages), and all the trouble that entails...
>:
>:Erm, all that is needed here is to hold the vm_mtx lock around the decrement.
>:Due to the nature of reference counts, there is no race condition so long as
>:everyone properly decrements the reference count by means of lock. Alfred's
>:VM
>:patch already does this. Also, Giant originally provided the lock around the
>:decrement.
>:
>:--
>:
>:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
>
> That isn't the problem. The problem is that the process can block
> in between the 'if (vm->vm_refcnt == 1)' test in exit1(), and the
> actual vmspace_free() in cpu_exit() (which occurs after the process
> has been reaped).
Err, you mean cpu_wait(). :)
> It is possible for the vm_refcnt check in exit1() to *NEVER* be 1
> if all the processes sharing the address space exit simultaniously
> and block anywhere between that check and the vmspace_free(). The
> result: shmexit() is never called.
IOW, the vmspace refcount is being (ab)used for the shm stuff. Why not move
the shmexit() to vmspace_free()? Hmm, I suppose the actual unmapping of all
the user pages has this problem as well? I guess that vmspace_free() happens
to hide that bug though as it will release the pages if they are still held in
vm_map_delete() and pmap_release(). If that is the case and it isn't harmful,
why not just postpone all the vmspace release and shmexit to cpu_wait?
As a side note, it looks like all of cpu_wait() could move into teh bottom of
wait1() and cpu_wait() could become an empty function right now. Nothing very
MD in it at the moment.
> -Matt
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
