Date: Mon, 21 May 2001 11:20:30 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: "Brian F. Feldman" <green@FreeBSD.ORG>, hackers@FreeBSD.ORG Subject: Re: RE: vmspace leak (+ tentative fix) Message-ID: <200105211820.f4LIKUs03769@earth.backplane.com> References: <XFMail.010521105854.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 <jhb@FreeBSD.org> -- 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105211820.f4LIKUs03769>