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] xen.git branch reorg / success with 2.6.30-rc3 pv_ops do

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 09 Jun 2009 10:28:35 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 09 Jun 2009 10:29:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1244476858.27370.325.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <20090522080655.GA24960@xxxxxxxxxxxxxxx> <20090604202656.GR24960@xxxxxxxxxxxxxxx> <1244197217.27370.146.camel@xxxxxxxxxxxxxxxxxxxxxx> <20090605112347.GY24960@xxxxxxxxxxxxxxx> <1244201864.27370.172.camel@xxxxxxxxxxxxxxxxxxxxxx> <20090605133850.GA24960@xxxxxxxxxxxxxxx> <1244209979.27370.188.camel@xxxxxxxxxxxxxxxxxxxxxx> <20090605154130.GB24960@xxxxxxxxxxxxxxx> <1244217948.27370.213.camel@xxxxxxxxxxxxxxxxxxxxxx> <1244218353.27370.216.camel@xxxxxxxxxxxxxxxxxxxxxx> <20090605181925.GC24960@xxxxxxxxxxxxxxx> <1244475935.27370.309.camel@xxxxxxxxxxxxxxxxxxxxxx> <1244476858.27370.325.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Ian Campbell wrote:
I wonder how this interacts with the logic in
arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
the (deferred) pin multicall to occur? Hmm, no this is about the
PagePinned flag on the struct page which is out of date WRT the actual
pinned status as Xen sees it -- we update the PagePinned flag early in
xen_pin_page() long before Xen the pin hypercall so this window is the
other way round to what would be needed to trigger this bug.

Yes, it looks like you could get a bad mapping here. An obvious fix would be to defer clearing the pinned flag in the page struct until after the hypercall has issued. That would make the racy kmap_atomic_pte map RO, which would be fine unless it actually tries to modify it (but I can't imagine it would do that unlocked).

   J

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

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