From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 14:01:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27B78106566C for ; Wed, 10 Jun 2009 14:01:03 +0000 (UTC) (envelope-from tim@tangobravo.co.uk) Received: from auth-1.ukservers.net (auth-1.ukservers.net [217.10.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id C0C688FC16 for ; Wed, 10 Jun 2009 14:01:02 +0000 (UTC) (envelope-from tim@tangobravo.co.uk) Received: from hades.syntheticmoon.co.uk (82-71-38-22.dsl.in-addr.zen.co.uk [82.71.38.22]) by auth-1.ukservers.net (Postfix smtp) with ESMTP id 4D6DD36F9D71 for ; Wed, 10 Jun 2009 14:38:13 +0100 (BST) Message-ID: <4A2FB742.6080307@tangobravo.co.uk> Date: Wed, 10 Jun 2009 14:38:10 +0100 From: Tim Borgeaud User-Agent: Thunderbird 2.0.0.21 (X11/20090911) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Jun 2009 15:55:47 +0000 Subject: Device drivers, mmap/munmap and freeing 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: Wed, 10 Jun 2009 14:01:03 -0000 I'm currently working on some wrappers and compatibility functions for allowing USB Linux device driver code to be compiled to create a FreeBSD driver module. I.e. extending the work of Luigi Rizzo (linux-kmod-compat) and/or the compatibility code now present in the FreeBSD USB stack. This approach, for creating drivers from Linux source, will probably be moved into userland in one way or another, but for now I'm going to see if I can make some progress by getting some Linux webcam drivers working. The problem I'm currently wrestling with is how to manage the emulation of Linux's mmapping. Linux driver code expects to be able to use some callback functions that are invoked when certain mmap related events occur. Drivers appear to use an open/close pair of functions that are called when a processes starts or stops using mapped memory. These are typically used to maintain a reference count for the memory. As far as I can tell, in FreeBSD, a vm_object_t also contains a similar reference count. The vm subsystem cleans up vm objects (and vm_map entries etc) when the reference count falls to zero. The trouble I have is that it appears that I'm going to need some way to let Linux driver code know whether or not some memory is still in use, i.e. whether the FreeBSD system still holds a vm_object for the mmapped memory. Ideally, I could invoke the Linux driver functions appropriately (when the vm subsystem increments or decrements reference counts for a vm_object). However, it should be enough just to make sure that the Linux driver close callback function is invoked when mapped memory has been unmapped. As far as I can tell, closing mapped file descriptors should not effect the reference count. It appears that it is quite legitimate to access mapped memory after the corresponing file descriptor has been closed. I'm wondering if there is any way to figure out whether some memory is still mapped (by the vm subsystem), whether or not a driver could be informed about munmapping (or forking etc) or what the possible effects would be if memory that has been mmapped is freed (while it may be in use). I suspect that applications will simply open, mmap and then close (and exit). So I think it would not be unreasonable to cause applications that work in some other way to fail. However, I also suspect that the failure resulting from attempts to access memory that has just been freed by a driver may be worse than a crashed application. Tim