From owner-freebsd-hackers Tue May 22 14:43:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E880737B422; Tue, 22 May 2001 14:43:30 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f4MLhSK50181; Tue, 22 May 2001 14:43:29 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f4MLhRM42436; Tue, 22 May 2001 14:43:27 -0700 (PDT) (envelope-from jhb) 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: <200105222139.f4MLdDs11003@earth.backplane.com> Date: Tue, 22 May 2001 14:43:27 -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 22-May-01 Matt Dillon wrote: >:>: >:>:John Baldwin -- http://www.FreeBSD.org/~jhb/ >:> >:> Huh? It doesn't look like the same algorithm to me. >: >:In exit1() we attempt to free resources early if we can. If we lose the >:race, >:we still clean it up in vmspace_free() called from cpu_wait(). If you check >:the shm pointer and do shmexit() in vmspace_free() just as is done in >:vmspace_free(), then you will catch any cases that fall through with the shm >:not being free'd using the same technique currently employed in releasing the >:vmspace and with a minimal amount of change to the code. >: >:-- >: >:John Baldwin -- http://www.FreeBSD.org/~jhb/ > > The whole point is to release resources as early as possible. Why would > you ever want to intentionally introduce a race that will 'sometimes' be > lost and thus cause a late resource release when you can just as easily > completely guarentee that the resource will be released early, and thus > never have to worry about it. That makes no sense at all. From the > point of view of algorithm design, it's much better to know what *will* > happen rather then what *might* happen. Then do you want to fix the race for the vmspace release as well? If so, that makes sense. Only doing one and not the other makes no sense though. It seemed you only wanted to close the shmexit() race but not the one for releasing the user pages. *shrug* -- 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