Date: Mon, 21 May 2001 12:35:17 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: hackers@FreeBSD.org, "Brian F. Feldman" <green@FreeBSD.org> Subject: Re: RE: vmspace leak (+ tentative fix) Message-ID: <200105211935.f4LJZHx05386@earth.backplane.com> References: <XFMail.010521122251.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>: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? 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). :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/ Yah, I'm sure there are a lot of MI/MD cleanups that could be done. -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?200105211935.f4LJZHx05386>