[lkml]   [2001]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: forcibly unmap pages in driver?
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()...


> >> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:54    [W:0.034 / U:1.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site