Matt Dillon <[EMAIL PROTECTED]> 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).
>
> 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.
That's exactly the race that I was referring too, though I was too tired at
the time to remember exactly when I posted the message; thanks :)
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED] `------------------------------'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
