From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 7 01:06:39 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 148BA16A420 for ; Tue, 7 Feb 2006 01:06:39 +0000 (GMT) (envelope-from freebsd@luna.afraid.org) Received: from gw.luna.afraid.org (lls-c-13303.adsl.wanadoo.nl [81.69.81.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C7CE43D46 for ; Tue, 7 Feb 2006 01:06:38 +0000 (GMT) (envelope-from freebsd@luna.afraid.org) Received: from [127.0.0.1] (gw.luna.afraid.org [127.0.0.1]) by gw.luna.afraid.org (Postfix) with ESMTP id C124D8; Tue, 7 Feb 2006 02:06:37 +0100 (CET) Message-ID: <43E7F29D.4040203@luna.afraid.org> Date: Tue, 07 Feb 2006 02:06:37 +0100 From: Raaf User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8) Gecko/20060118 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: John-Mark Gurney References: <43E7C583.3040904@luna.afraid.org> <20060206225649.GJ69162@funkthat.com> <43E7ED06.4030403@luna.afraid.org> <20060207005506.GL69162@funkthat.com> In-Reply-To: <20060207005506.GL69162@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Freeing mmapped memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2006 01:06:39 -0000 John-Mark Gurney wrote: > Raaf wrote this message on Tue, Feb 07, 2006 at 01:42 +0100: >> John-Mark Gurney wrote: >>> Raaf wrote this message on Mon, Feb 06, 2006 at 22:54 +0100: >>>> Hi, i am working on a usb driver that allocates some memory when >>>> the device is opened using malloc. >>>> >>>> Now i want user processes to be able to access this memory using >>>> mmap and i want to free this memory when it is no longer needed. >>>> >>>> The problem is that there seems to be no way of knowing for my >>>> driver at what time the memory is no longer mapped in a process >>>> address space so that i can safely free this memory. >>> why not at close time? I would imagine that the device won't be closed >>> until all the mmap's that are backed by the device are unmapped.. it >>> shouldn't be hard to test... the mapping should hold a reference to >>> the device until it's munmapped.. >>> >> The problem is that it is perfectly legal to access the mapped memory >> after a close, consider following code: >> >> fd = open() >> mem = mmap() >> close(fd) >> process_data(mem) >> >> Unfortunately the mapping doesn't seem to hold a reference to the >> related fileobject, so the close in above code actually ends up >> in the close function of my driver but the mapping is still there. > > and you've tested that the mmap function still gets called after the > close function of your device driver is? Yes, just tested it with some printf's in the driver. open mmap close mmap > If this is the case, we need > to fix FreeBSD.. the mmap should increase the ref count on the device, > and the close shouldn't initiate the close until the mapping goes away.. > That would be nice. > fd = open() # ref cnt = 1 > mem = mmap() # ref cnt++ > close(fd) # ref cnt-- > process_data(mem) # valid ref cnt > 0 > munmap(mem) # ref cnt-- and close sine ref cnt == 0 >