From: Andi Kleen Subject: Re: Interaction between Xen and XFS: stray RW mappings Date: Mon, 22 Oct 2007 15:47:27 +0200 Message-ID: References: <470FA7C3.90404@goop.org> <20071014225618.GN23367404@sgi.com> <4712A254.4090604@goop.org> <200710151415.07248.nickpiggin@yahoo.com.au> <471C1A61.1010001@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <471C1A61.1010001@goop.org> (Jeremy Fitzhardinge's message of "Sun\, 21 Oct 2007 20\:34\:57 -0700") Sender: linux-kernel-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: dean gaudet , Nick Piggin , Xen-devel , Morten@suse.de, David Chinner , Linux Kernel Mailing List , =?iso-8859-1?Q?B=F8geskov?= , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge 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. -Andi