WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests

To: "Grzegorz Milos" <gm281@xxxxxxxxx>, "Patrick Colp" <pjcolp@xxxxxxxxx>, "Andrew Peace" <Andrew.Peace@xxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 04 Jan 2010 14:14:01 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 04 Jan 2010 06:14:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <db8ce2bd0912161514s7a162546gf7f5909db22e274c@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <db8ce2bd0912161514s7a162546gf7f5909db22e274c@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Grzegorz Milos <gm281@xxxxxxxxx> 17.12.09 00:14 >>>
One more issue I see with these changes:

>--- a/drivers/xen/privcmd/privcmd.c
>+++ b/drivers/xen/privcmd/privcmd.c
>...
>@@ -236,8 +237,14 @@ static long privcmd_ioctl(struct file *f
>                   (m.addr != vma->vm_start) ||
>                   ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
>                   !privcmd_enforce_singleshot_mapping(vma)) {
>-                      up_write(&mm->mmap_sem);
>-                      goto mmapbatch_out;
>+                      if (!(vma &&
>+                            (m.addr >= vma->vm_start) &&
>+                            ((m.addr + (nr_pages << PAGE_SHIFT)) <= 
>vma->vm_end) &&
>+                            (nr_pages == 1) &&
>+                            !privcmd_enforce_singleshot_mapping(vma))) {
>+                              up_write(&mm->mmap_sem);
>+                              goto mmapbatch_out;
>+                      }
>               }
> 
>               p = m.arr;

Isn't this undermining the purpose of privcmd_enforce_singleshot_mapping()?
You don't check that the eventual single page re-mapping attempt is
really due to an earlier -ENOENT failure, and hence the whole single
shot mapping checks are now pointless (though other than possibly to
enforce some minimal security I don't really know what its purpose
is/was - Keir?).

Jan


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

<Prev in Thread] Current Thread [Next in Thread>