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] GNTTABOP_unmap_grant_ref

To: "King, Steven R" <steven.r.king@xxxxxxxxx>
Subject: Re: [Xen-devel] GNTTABOP_unmap_grant_ref
From: Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>
Date: Wed, 25 Jan 2006 20:32:55 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Jan 2006 04:41:44 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rekg2OIYWqdPTqHQbavdZufrztOGXIzBSfULjWyZWBbE7lMke36S+oUJJSv56itL0g5mTXaEeDoxRIitQM7lCKg8Q3is/fLPyXsy+FmGl1o1s/KT7JLTYTcRYKK+F13LJGmNTIU9arOBgjvtXr2AiWu2D8+r1Jv95rPvL2kjiJw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <44BDAFB888F59F408FAE3CC35AB4704102D88704@orsmsx409>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44BDAFB888F59F408FAE3CC35AB4704102D88704@orsmsx409>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 1/24/06, King, Steven R <steven.r.king@xxxxxxxxx> wrote:
> Vma->close() didn't work.  Thanks for the great suggestion though.  :^)

I've run up against this in the past.  Linux vmas don't have a hook
point that allows you to clean things up before the associated PTEs
are zapped, and so you are forced to take the implicit unmap path if
you unexpectedly destroy an mmaped region containing grants without
cleaning them up properly.  One solution would be to add a new vma
destructor op that gets called prior to the zap and then let your
driver clean things up there.  I have no idea if this would fly with
the LKML folk though. ;)

Fixing the implicit unmap code to automagically clean up on (e.g.) vma
destruction is not the correct solution.  There isn't enough
information to associate a mapped PTE to the appropriate active grant,
and i don't think we want to add the space overhead in Xen required to
track this sort of thing just to babysit VMs that don't clean things
up correctly.  If a grant is mapped multiple times, the implicit unmap
code has no way to tell which active grant to garbage collect, and
things can go terribly wrong.  As other people have said, grants to
user space are rather less thoroughly tested, but an extra vma op
seems to me to be a good solution.

a.

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

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