6 messages in com.xensource.lists.xen-develRE: [Xen-devel] GNTTABOP_unmap_grant_ref
FromSent OnAttachments
King, Steven R24 Jan 2006 15:28 
Muli Ben-Yehuda24 Jan 2006 15:49 
King, Steven R24 Jan 2006 17:32 
Mark Williamson24 Jan 2006 17:47 
Keir Fraser25 Jan 2006 02:06 
Andrew Warfield25 Jan 2006 20:32 
Subject:RE: [Xen-devel] GNTTABOP_unmap_grant_ref
From:King, Steven R (stev@intel.com)
Date:01/24/2006 05:32:45 PM
List:com.xensource.lists.xen-devel

Vma->close() didn't work. Thanks for the great suggestion though. :^)

To verify that I wasn't making some new mistake, inspection of linux/mm/mmap.c shows that Linux calls vma->close() *after* the page table manipulation. In do_munmap(), the sequence is:

detach_vmas_to_be_unmapped() unmap_region() <--- page table manipulation buried in here remove_vma_list() <--- vma->close() buried in here

Is this turning into a Xen problem? Why does Xen forbid implicit unmapping of shared pages?

-steve

-----Original Message----- From: xen-@lists.xensource.com [mailto:xen-@lists.xensource.com] On Behalf Of Muli Ben-Yehuda Sent: Tuesday, January 24, 2006 3:50 PM To: King, Steven R Cc: xen-devel; Mark Williamson Subject: Re: [Xen-devel] GNTTABOP_unmap_grant_ref

On Tue, Jan 24, 2006 at 03:28:55PM -0800, King, Steven R wrote:

I have not yet found a way to make the GNTTABOP_unmap_grant_ref() call

in time to avoid the crash. The driver release() function is too late

and there's no hook in struct file_operations to handle unmap explicitly.

Could you hook the vma->close function? ISTR it gets called on unmap. If this is too fine grained or is not called on every munmap (unmapping of partial VMAs?), you could clean up all mappings when the file that the application mmap's is closed.

Cheers, Muli