linux-kernel - patch xen-xfs-unmap.patch queued to -stable tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20071113225059.9B93E14544CD@imap.suse.de>
Date:	Tue, 13 Nov 2007 14:50:48 -0800
From:	<gregkh@...e.de>
To:	jeremy@...p.org, ak@....de, akpm@...ux-foundation.org,
	chrisw@...s-sol.org, gregkh@...e.de, jeremy@...source.com,
	keir@...source.com, linux-kernel@...r.kernel.org,
	mark.williamson@...cam.ac.uk, stable@...nel.org,
	xen-users@...ten.bogeskov.dk, xfs-masters@....sgi.com
Cc:	<stable@...nel.org>, <stable-commits@...r.kernel.org>
Subject: patch xen-xfs-unmap.patch queued to -stable tree


This is a note to let you know that we have just queued up the patch titled

     Subject: xfs: eagerly remove vmap mappings to avoid upsetting Xen

to the 2.6.23-stable tree.  Its filename is

     xen-xfs-unmap.patch

A git repo of this tree can be found at 
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary


>From stable-bounces@...ux.kernel.org Fri Oct 12 14:33:36 2007
From: Jeremy Fitzhardinge <jeremy@...p.org>
Date: Fri, 12 Oct 2007 14:11:42 -0700
Subject: xfs: eagerly remove vmap mappings to avoid upsetting Xen
To: LKML <linux-kernel@...r.kernel.org>
Cc: xen-devel@...ts.xensource.com, virtualization@...ts.osdl.org, Mark Williamson <mark.williamson@...cam.ac.uk>, XFS masters <xfs-masters@....sgi.com>, Chris Wright <chrisw@...s-sol.org>, Andi Kleen <ak@....de>, Morten Bøgeskov <xen-users@...ten.bogeskov.dk>, Andrew Morton <akpm@...ux-foundation.org>, Keir Fraser <keir@...source.com>, Stable kernel <stable@...nel.org>
Message-ID: <20071012211148.864500000@...p.org>
Content-Disposition: inline; filename=xen-xfs-unmap.patch

From: Jeremy Fitzhardinge <jeremy@...p.org>

patch ace2e92e193126711cb3a83a3752b2c5b8396950 in mainline.

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.

[ Stable: This works around a bug in 2.6.23.  We may come up with a
better solution for mainline, but this seems like a low-impact fix for
the stable kernel. ]

Signed-off-by: Jeremy Fitzhardinge <jeremy@...source.com>
Cc: XFS masters <xfs-masters@....sgi.com>
Cc: Morten =?utf-8?q?B=C3=B8geskov?= <xen-users@...ten.bogeskov.dk>
Cc: Mark Williamson <mark.williamson@...cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>


---
 fs/xfs/linux-2.6/xfs_buf.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/fs/xfs/linux-2.6/xfs_buf.c
+++ b/fs/xfs/linux-2.6/xfs_buf.c
@@ -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);


Patches currently in stable-queue which might be from jeremy@...p.org are

queue-2.6.23/xen-handle-lazy-cr3-on-unpin.patch
queue-2.6.23/xen-multicall-callbacks.patch
queue-2.6.23/xen-fix-register_vcpu_info.patch
queue-2.6.23/xen-xfs-unmap.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/