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/
Home Products Support Community News


[Xen-changelog] [xen-3.1-testing] xfs: eagerly remove vmap mappings to a

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-3.1-testing] xfs: eagerly remove vmap mappings to avoid upsetting Xen
From: "Xen patchbot-3.1-testing" <patchbot-3.1-testing@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 19 Oct 2007 11:00:37 -0700
Delivery-date: Fri, 19 Oct 2007 11:01:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User Keir Fraser <keir@xxxxxxxxxxxxx>
# Date 1192783426 -3600
# Node ID 0696d1ad7f1491c190df397337179207570bbdba
# Parent  6b9afd5b590780eb63fc89f775d4cf40ea2b32c8
xfs: eagerly remove vmap mappings to avoid upsetting Xen
XFS leaves stray mappings around when it vmaps memory to make it
virtually contigious.  This upsets Xen if one of those pages is being
recycled into a pagetable, since it finds an extra writable mapping of
the page.

This patch solves the problem in a brute force way, by making XFS
always eagerly unmap its mappings.  David Chinner says this shouldn't
have any performance impact on filesystems with default block sizes;
it will only affect filesystems with large block sizes.

Signed-off-by: Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>
Acked-by: David Chinner <dgc@xxxxxxx>
Cc: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
Cc: XFS masters <xfs-masters@xxxxxxxxxxx>
Cc: Stable kernel <stable@xxxxxxxxxx>
Cc: Morten Bogeskov <xen-users@xxxxxxxxxxxxxxxxxx>
Cc: Mark Williamson <mark.williamson@xxxxxxxxxxxx>

linux-2.6.18-xen changeset:   263:9bf1ddd0f6bf57684c5b0307a43ea381c45f5147
linux-2.6.18-xen date:        Wed Oct 17 09:24:03 2007 +0100
 linux-2.6-xen-sparse/fs/xfs/linux-2.6/xfs_buf.c |   13 +++++++++++++
 1 files changed, 13 insertions(+)

diff -r 6b9afd5b5907 -r 0696d1ad7f14 
--- a/linux-2.6-xen-sparse/fs/xfs/linux-2.6/xfs_buf.c   Fri Oct 19 09:42:42 
2007 +0100
+++ b/linux-2.6-xen-sparse/fs/xfs/linux-2.6/xfs_buf.c   Fri Oct 19 09:43:46 
2007 +0100
@@ -181,6 +181,19 @@ free_address(
        void            *addr)
        a_list_t        *aentry;
+#ifdef CONFIG_XEN
+       /*
+        * Xen needs to be able to make sure it can get an exclusive
+        * RO mapping of pages it wants to turn into a pagetable.  If
+        * a newly allocated page is also still being vmap()ed by xfs,
+        * it will cause pagetable construction to fail.  This is a
+        * quick workaround to always eagerly unmap pages so that Xen
+        * is happy.
+        */
+       vunmap(addr);
+       return;
        aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT);
        if (likely(aentry)) {

Xen-changelog mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-3.1-testing] xfs: eagerly remove vmap mappings to avoid upsetting Xen, Xen patchbot-3.1-testing <=