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

[Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings
From: David Chinner <dgc@xxxxxxx>
Date: Tue, 23 Oct 2007 08:32:25 +1000
Cc: Nick Piggin <nickpiggin@xxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, dean gaudet <dean@xxxxxxxxxx>, David Chinner <dgc@xxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Bøgeskov <xen-users@xxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Morten@xxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Mon, 22 Oct 2007 15:33:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071022190740.GA1695@xxxxxxxxxxxxxxxxxx>
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: <470FA7C3.90404@xxxxxxxx> <20071014225618.GN23367404@xxxxxxx> <4712A254.4090604@xxxxxxxx> <200710151415.07248.nickpiggin@xxxxxxxxxxxx> <alpine.DEB.0.9999.0710212015430.2320@xxxxxxxxxxxxxxxxxxx> <471C1A61.1010001@xxxxxxxx> <p73sl439s7k.fsf@xxxxxxxxxxxxxx> <471CEEB4.9040807@xxxxxxxx> <20071022190740.GA1695@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote:
> On Mon, Oct 22, 2007 at 11:40:52AM -0700, Jeremy Fitzhardinge wrote:
> > Andi Kleen wrote:
> > > Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
> > >   
> > >> Yes, that's precisely the problem.  xfs does delay the unmap, leaving
> > >> stray mappings, which upsets Xen.
> > >>     
> > >
> > > Again it not just upsets Xen, keeping mappings to freed pages is wrong 
> > > generally 
> > > and violates the x86 (and likely others like PPC) architecture because it 
> > > can 
> > > cause illegal caching attribute aliases.
> > >
> > > The patch that went into the tree was really not correct -- this
> > > bogus optimization should have been unconditionally removed
> > > or if you really wanted an ifdef made dependent on !CONFIG_XEN &&
> > > !CONFIG_AGP (and likely && !CONFIG_DRM && !CONFIG_anything else that
> > > uses uncached mappings in memory). 
> > >
> > > You just worked around the obvious failure and leave the non obvious
> > > rare corruptions in, which isn't a good strategy.
> > 
> > Well, at least it becomes a known issue and/or placeholder for when Nick
> 
> It's hidden now so it causes any obvious failures any more. Just
> subtle ones which is much worse.

There's no evidence of any problems ever being caused by this code.
It's been there for years.

> But why not just disable it?  It's not critical functionality,
> just a optimization that unfortunately turned out to be incorrect.

It is critical functionality for larger machines because vmap()/vunmap()
really does suck in terms of scalability.

> It could be made correct short term by not freeing the pages until
> vunmap for example.

Could vmap()/vunmap() take references to the pages that are
mapped? That way delaying the unmap would also delay the freeing
of the pages and hence we'd have no problems with the pages
being reused before the mapping is torn down. That'd work for
Xen even with XFS's lazy unmapping scheme, and would allow
Nick's more advanced methods to work as well....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

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

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