From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: xen.git branch reorg / success with 2.6.30-rc3	pv_ops
	dom0
Date: Tue, 09 Jun 2009 10:28:35 -0700
Message-ID: <4A2E9BC3.4060507@goop.org>
References: <20090522080655.GA24960@edu.joroinen.fi>	
	<20090604202656.GR24960@edu.joroinen.fi>	
	<1244197217.27370.146.camel@zakaz.uk.xensource.com>	
	<20090605112347.GY24960@edu.joroinen.fi>	
	<1244201864.27370.172.camel@zakaz.uk.xensource.com>	
	<20090605133850.GA24960@edu.joroinen.fi>	
	<1244209979.27370.188.camel@zakaz.uk.xensource.com>	
	<20090605154130.GB24960@edu.joroinen.fi>	
	<1244217948.27370.213.camel@zakaz.uk.xensource.com>	
	<1244218353.27370.216.camel@zakaz.uk.xensource.com>	
	<20090605181925.GC24960@edu.joroinen.fi>	
	<1244475935.27370.309.camel@zakaz.uk.xensource.com>
	<1244476858.27370.325.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <1244476858.27370.325.camel@zakaz.uk.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

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