Re: Re: Next steps with pv_ops for Xen

[Derek Murray <Derek.Murray@cl.cam.ac.uk>]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Gerd,

Can you try the attached patch against linux-2.6.18-xen.hg?

I think the problem was that the gntdev VMA is not marked as being 
VM_PFNMAP, therefore it tries to get a struct page_struct for each 
granted page when it is unmapped (and maybe sometimes succeeds 
(incorrectly), which could be why I haven't seen the bug). With this 
flag, vm_normal_page will return NULL in zap_pte_range, and so the code 
that decrements that reference count will not be executed.

Regards,

Derek.

[-- Attachment #2: gntdev_vm_pfnmap.patch --]
[-- Type: text/x-patch, Size: 1073 bytes --]

# HG changeset patch
# User dgm36@ise.cl.cam.ac.uk
# Date 1196860382 0
# Node ID af26b3dd23822190acbec1872a47259e1fed88b8
# Parent  b2768401db943e66af9d64bd610ffa225f560c0b
Set gntdev VMA to be VM_PFNMAP.

diff -r b2768401db94 -r af26b3dd2382 drivers/xen/gntdev/gntdev.c
--- a/drivers/xen/gntdev/gntdev.c	Mon Dec 03 08:50:12 2007 +0000
+++ b/drivers/xen/gntdev/gntdev.c	Wed Dec 05 13:13:02 2007 +0000
@@ -501,6 +501,17 @@ static int gntdev_mmap (struct file *fli
     
 	/* The VM area contains pages from another VM. */
 	vma->vm_flags |= VM_FOREIGN;
+
+	/* The VM area contains pages that are not backed by page_structs in
+	 * this domain's memory map.
+	 *
+	 * TODO/FIXME?: We should probably use the VM_FOREIGN workaround as
+	 *              used by get_user_pages() to provide access to the
+	 *              page_structs for each page, but I'm not sure if that's
+	 *              necessary.
+	 */
+	vma->vm_flags |= VM_PFNMAP;
+
 	vma->vm_private_data = kzalloc(size * sizeof(struct page_struct *), 
 				       GFP_KERNEL);
 	if (vma->vm_private_data == NULL) {

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel