From: Alan Stern > Sent: 15 December 2015 15:13 ... > > I was thinking that some side effect of dma_free_coherent() would > > find the user mapping for the pages, force unmap them and invalidate > > the user PTE (although the address range would have to remain reserved). > > Maybe that is wishful thinking. > > It is. dma_free_coherent() does nothing but remove the DMA mapping and > deallocate the memory. It doesn't touch any user page mappings. > > > Similarly for iounmap(). > > > > > In theory we could prevent this problem by unmapping the memory when > > > the file descriptor is closed. But doing so would violate the > > > guarantee in the munmap(2) documentation. > > > > That doesn't help. > > The mapping is inherited by fork() but you only see the last close(). > > So the close() need not be in the context of the process that has > > the pages mapped. > > 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. This ordering is more important if vm_iomap_memory() is used since iounmap() has to be called from the .remove() entry for the hardware. David -- 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
