[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] GNTTABOP_unmap_grant_ref

  • To: "King, Steven R" <steven.r.king@xxxxxxxxx>
  • 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=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.