Date: Mon, 21 May 2001 12:46:13 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Brian F. Feldman" <green@FreeBSD.org>, hackers@FreeBSD.org Subject: Re: RE: vmspace leak (+ tentative fix) Message-ID: <XFMail.010521124613.jhb@FreeBSD.org> In-Reply-To: <200105211935.f4LJZHx05386@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21-May-01 Matt Dillon wrote: > >:>:John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ >: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? > > It's important to release resources as early as possible, so zombied > processes don't run the machine out of memory if a parent forgets to > reap its children. You can also get into non-optimal VM interactions > with fork()ing servers if you delay resource freeing when a child > exits (for example, Apache). Also, as per the comment, some things you > have to do while the process is still capable of blocking. This is > why the hack is in there. It is somewhat redundant... you are right, > only the shared memory piece is left hanging when all is said and done. > > Unfortunately when the shared vm space capability was originally added, > the authors introduced a couple of bugs. This is one of them (the > other biggy was with file descriptor open/close/dup races). Ok, then why not let the current shmexit() stay in exit1() as a hack to help free memory, but add in a check in vmspace_free() as well to catch any race conditions that may fall through the cracks? As long as we clear the shm pointer in struct vmspace when we free it then we won't be double free'ing, and will always free it eventually. That is also a much simpler change. :) Additionally, adding to the comment in exit1() clarifying that this is an attempt to free resources as soon as possible and that the race condition is known and that vmspace_free() is a catch-all might be nice as well. -- 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.010521124613.jhb>