Date: Mon, 21 May 2001 12:22:51 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: hackers@FreeBSD.org, "Brian F. Feldman" <green@FreeBSD.org> Subject: Re: RE: vmspace leak (+ tentative fix) Message-ID: <XFMail.010521122251.jhb@FreeBSD.org> In-Reply-To: <200105211820.f4LIKUs03769@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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). 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 <jhb@FreeBSD.org> -- 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 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?XFMail.010521122251.jhb>