From owner-freebsd-hackers Mon May 21 12:23: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 53DF837B422; Mon, 21 May 2001 12:22:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4LJMiG46562; Mon, 21 May 2001 12:22:44 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200105211820.f4LIKUs03769@earth.backplane.com> Date: Mon, 21 May 2001 12:22:51 -0700 (PDT) From: John Baldwin To: Matt Dillon Subject: Re: RE: vmspace leak (+ tentative fix) Cc: hackers@FreeBSD.org, "Brian F. Feldman" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 -- 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 -- 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