From: <gregkh@suse.de>
To: jeremy@goop.org, ak@muc.de, akpm@linux-foundation.org,
chrisw@sous-sol.org, gregkh@suse.de, jeremy@xensource.com,
keir@xensource.com, linux-kernel@vger.kernel.org,
mark.williamson@cl.cam.ac.uk, stable@kernel.org,
xen-users@morten.bogeskov.dk, xfs-masters@oss.sgi.com
Cc: <stable@kernel.org>, <stable-commits@vger.kernel.org>
Subject: patch xen-xfs-unmap.patch queued to -stable tree
Date: Tue, 13 Nov 2007 14:50:48 -0800 [thread overview]
Message-ID: <20071113225059.9B93E14544CD@imap.suse.de> (raw)
In-Reply-To: <20071012211148.864500000@goop.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2894 bytes --]
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@linux.kernel.org Fri Oct 12 14:33:36 2007
From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Fri, 12 Oct 2007 14:11:42 -0700
Subject: xfs: eagerly remove vmap mappings to avoid upsetting Xen
To: LKML <linux-kernel@vger.kernel.org>
Cc: xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Mark Williamson <mark.williamson@cl.cam.ac.uk>, XFS masters <xfs-masters@oss.sgi.com>, Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>, Morten Bøgeskov <xen-users@morten.bogeskov.dk>, Andrew Morton <akpm@linux-foundation.org>, Keir Fraser <keir@xensource.com>, Stable kernel <stable@kernel.org>
Message-ID: <20071012211148.864500000@goop.org>
Content-Disposition: inline; filename=xen-xfs-unmap.patch
From: Jeremy Fitzhardinge <jeremy@goop.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@xensource.com>
Cc: XFS masters <xfs-masters@oss.sgi.com>
Cc: Morten =?utf-8?q?B=C3=B8geskov?= <xen-users@morten.bogeskov.dk>
Cc: Mark Williamson <mark.williamson@cl.cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.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@goop.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
prev parent reply other threads:[~2007-11-13 22:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 21:11 [PATCH 00/10] REVIEW: Xen patches for 2.6.24 Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 01/10] remove dead code in pgtable_cache_init Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 02/10] Clean up duplicate includes in arch/i386/xen/ Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 03/10] xen: yield to IPI target if necessary Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 04/10] xen: add batch completion callbacks Jeremy Fitzhardinge
2007-11-13 22:50 ` patch xen-multicall-callbacks.patch queued to -stable tree gregkh
2007-10-12 21:11 ` [PATCH 05/10] xen: deal with stale cr3 values when unpinning pagetables Jeremy Fitzhardinge
2007-11-13 22:50 ` patch xen-handle-lazy-cr3-on-unpin.patch queued to -stable tree gregkh
2007-10-12 21:11 ` [PATCH 06/10] xen: lock pte pages while pinning/unpinning Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 07/10] xen: ask the hypervisor how much space it needs reserved Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 08/10] xen: fix incorrect vcpu_register_vcpu_info hypercall argument Jeremy Fitzhardinge
2007-11-13 22:50 ` patch xen-fix-register_vcpu_info.patch queued to -stable tree gregkh
2007-10-12 21:11 ` [PATCH 09/10] xen: add some debug output for failed multicalls Jeremy Fitzhardinge
2007-10-12 21:11 ` [PATCH 10/10] xfs: eagerly remove vmap mappings to avoid upsetting Xen Jeremy Fitzhardinge
2007-11-13 22:50 ` gregkh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071113225059.9B93E14544CD@imap.suse.de \
--to=gregkh@suse.de \
--cc=ak@muc.de \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=jeremy@goop.org \
--cc=jeremy@xensource.com \
--cc=keir@xensource.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.williamson@cl.cam.ac.uk \
--cc=stable-commits@vger.kernel.org \
--cc=stable@kernel.org \
--cc=xen-users@morten.bogeskov.dk \
--cc=xfs-masters@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®