Device drivers, mmap/munmap and freeing memory

Tim Borgeaud tim at tangobravo.co.uk
Wed Jun 10 14:01:03 UTC 2009


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


More information about the freebsd-hackers mailing list