From owner-freebsd-hackers Mon May 21 22:17:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from green.bikeshed.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B48637B424; Mon, 21 May 2001 22:17:55 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f4M5Hsl13434; Tue, 22 May 2001 01:17:54 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200105220517.f4M5Hsl13434@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Matt Dillon Cc: John Baldwin , hackers@FreeBSD.ORG Subject: Re: vmspace leak (+ tentative fix) In-Reply-To: Message from Matt Dillon of "Mon, 21 May 2001 11:20:30 PDT." <200105211820.f4LIKUs03769@earth.backplane.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 May 2001 01:17:53 -0400 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 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). > > 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. That's exactly the race that I was referring too, though I was too tired at the time to remember exactly when I posted the message; thanks :) -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message