All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: <xen-devel@lists.xen.org>, <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v3] p2m: use GNTTABOP_unmap_and_duplicate if available
Date: Thu, 7 Nov 2013 11:12:52 +0000	[thread overview]
Message-ID: <527B75B4.20700@citrix.com> (raw)
In-Reply-To: <1383579524-12465-1-git-send-email-roger.pau@citrix.com>

On 04/11/13 15:38, Roger Pau Monne wrote:
> The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
> mapping passed in new_addr, allowing us to perform batch unmaps in p2m
> code without requiring the use of a multicall.

I have recently investigated some problems that were caused by a user
space process using gntdev.  It was unmapping page that still had
outstanding I/O.  This caused a number of failures:

1. Oopses due to swiotlb_bounce() attempting to memcpy() back to a page
that now has a read-only mapping to a scratch page MFN.

2. Bad page errors due to the balloon page being freed by gntdev while
the page count > 1 and the balloon driver setting page count to 1 and
freeing the page.

I think we need to take a step back and look at the design of the gntdev
device to make it handle misbehaved or crashing programs.

In particular, I think we need to use regular (non-ballooned) pages and
restore their original direct mappings when grant unmapping.  My initial
thoughts are that this would require a GNTTABOP_unmap_and_replace
variant that takes a GFN direct instead of a finding the GFN via a
virtual address.

I think it is best to hold off on any optimization attempts here until
we get the gntdev design right.

David

  parent reply	other threads:[~2013-11-07 11:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 15:38 [PATCH v3] p2m: use GNTTABOP_unmap_and_duplicate if available Roger Pau Monne
2013-11-04 15:49 ` [Xen-devel] " Ian Campbell
2013-11-04 16:09   ` Roger Pau Monné
2013-11-04 16:26     ` Ian Campbell
2013-11-04 16:26     ` [Xen-devel] " Ian Campbell
2013-11-04 16:09   ` Roger Pau Monné
2013-11-04 15:49 ` Ian Campbell
2013-11-05 10:47 ` David Vrabel
2013-11-05 10:47 ` David Vrabel
2013-11-07 11:12 ` David Vrabel [this message]
2013-11-07 11:12 ` David Vrabel
  -- strict thread matches above, loose matches on Subject: below --
2013-11-04 15:38 Roger Pau Monne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527B75B4.20700@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roger.pau@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.