Re: forcibly unmap pages in driver?

[Dan Maas]

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).