forcibly unmap pages in driver?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Just an update to my situation... I've implemented my idea of clearing the associated PTE's when I need to free the DMA buffer, then re-filling them in nopage(). This seems to work fine; if the user process tries anything fishy, it gets a SIGBUS instead of accessing the old mapping.
I encountered two difficulties with the implementation:
1) zap_page_range(), flush_cache_range(), and flush_tlb_range() are not exported to drivers. I basically copied the guts of zap_page_range() into my driver, which seems to work OK on x86, but I know it will have trouble with architectures that require special treatment of PTE manipulation...
2) the state of mm->mmap_sem is unknown when my file_operations->release() function is called. If release() is called when the last FD closes, then mm->mmap_sem is not taken. But if release() is called from do_munmap, then mmap_sem has already been taken. So, it is risky to mess with vma's inside of release()...
Regards,
Dan
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines
Later, the program calls the
ioctl()again to set a smaller buffer size, or closes the file descriptor. At this point I'd like to shrink the buffer or free it completely. But I can't assume that the program will be nice andmunmap()the region for meLook at
drivers/char/drm, for example. At mmap time they allocate avm_opsto the address space. With that you catch changes to the vma structure initiated by a user mmap, munmap, etc. You could also dynamically map the pages in using the nopage method (optional).