[XFS] eagerly remove vmap mappings to avoid upsetting Xen
authorJeremy Fitzhardinge <jeremy@xensource.com>
Wed, 17 Oct 2007 03:55:03 +0000 (13:55 +1000)
committerTim Shimmin <tes@chook.melbourne.sgi.com>
Wed, 17 Oct 2007 04:14:35 +0000 (14:14 +1000)
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.

SGI-PV: 971902
SGI-Modid: xfs-linux-melb:xfs-kern:29886a

Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Tim Shimmin <tes@sgi.com>
fs/xfs/linux-2.6/xfs_buf.c

index 8d9298c99763f9a5f090fd63992096a5f2ac86fa..d5b2d2bbf5ff89536e53f4a148095d3052036e48 100644 (file)
@@ -187,6 +187,19 @@ free_address(
 {
        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;
+#endif
+
        aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT);
        if (likely(aentry)) {
                spin_lock(&as_lock);