From owner-freebsd-hackers Tue May 22 14:53:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3108437B43C; Tue, 22 May 2001 14:53:16 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4MLrFe11250; Tue, 22 May 2001 14:53:15 -0700 (PDT) (envelope-from dillon) Date: Tue, 22 May 2001 14:53:15 -0700 (PDT) From: Matt Dillon Message-Id: <200105222153.f4MLrFe11250@earth.backplane.com> To: John Baldwin Cc: hackers@FreeBSD.org, "Brian F. Feldman" Subject: Re: RE: vmspace leak (+ tentative fix) References: 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 :> :> 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/ The patch I suggested removes the race, period. So all the code in the initial conditional gets run... the shmexit as well as releasing the user pages. Since the two are side by side it would be kinda difficult to run one but not the other so I'm not sure where the confusion could have been introduced. We might also want to add the shmexit to the vmspace_free() code for completeness, but that would require more research to determine whether it's safe to do there or not. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message