[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <470FA7C3.90404@goop.org>
Date: Fri, 12 Oct 2007 09:58:43 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: David Chinner <dgc@....com>
CC: xfs@....sgi.com, Xen-devel <xen-devel@...ts.xensource.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mark Williamson <mark.williamson@...cam.ac.uk>,
Morten Bøgeskov
<xen-users@...ten.bogeskov.dk>, xfs-masters@....sgi.com
Subject: Interaction between Xen and XFS: stray RW mappings
Hi Dave & other XFS folk,
I'm tracking down a bug which appears to be a bad interaction between
XFS and Xen. It looks like XFS is holding RW mappings on free pages,
which Xen is trying to get an exclusive RO mapping on so it can turn
them into pagetables.
I'm assuming the pages are actually free, and this isn't a use after
free problem. From a quick poke around, the most likely pieces of XFS
code is the stuff in xfs_map.c which creates a virtually contiguous
mapping of pages with vmap, and seems to delay unmapping them.
When pinning a pagetable, Xen tries to eliminate any RW aliases of the
pages its using. This is generally trivial because pages returned by
get_free_page don't have any mappings aside from the normal kernel
mapping. High pages, when using CONFIG_HIGHPTE, may have a residual
kmap mapping, so we clear out the kmap cache if we encounter a highpage
in the pagetable.
I guess we could create a special-case interface to do the same thing
with XFS mappings, but it would be nicer to have something more generic.
Is my analysis correct? Or should XFS not be holding stray mappings?
Or is there already some kind of generic mechanism I can use to get it
to release its mappings?
Thanks,
J
-
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/
Powered by blists - more mailing lists