On Tue, 15 Dec 2015, David Laight wrote: > > Good point. So it seems that the try_module_get() / module_put() > > solution is the only one. > > That still isn't entirely correct. > > Someone with more knowledge than either of us has needs to sort out > how to handle this properly. > > Before calling dma_free_coherent() you (and I) need to invalidate all > the vma mappings that reference the memory - so that any accesses > will call the vma_ops.fault() code which will return VM_FAULT_SIGBUS. > Then you need to hold the module present until all the mappings are > removed. Don't the vma mappings get invalidated before the vm_operations_struct's ->close method is called? In other words, when a process calls munmap() or exits? The try_module_get() will hold the module present until the ->close method has been called for all the mappings. > This ordering is more important if vm_iomap_memory() is used since > iounmap() has to be called from the .remove() entry for the hardware. Fortunately we're not concerned with iomem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html