Messages in this thread | | | From | "Dan Maas" <> | Subject | Re: forcibly unmap pages in driver? | Date | Wed, 6 Jun 2001 23:46:05 -0400 |
| |
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
> >> 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 and munmap() the > >> region for me > > > Look at drivers/char/drm, for example. At mmap time they allocate a > > vm_ops to 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).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |