[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071023092838.GA24536@one.firstfloor.org>
Date: Tue, 23 Oct 2007 11:28:38 +0200
From: Andi Kleen <andi@...stfloor.org>
To: David Chinner <dgc@....com>
Cc: Andi Kleen <andi@...stfloor.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
dean gaudet <dean@...tic.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Xen-devel <xen-devel@...ts.xensource.com>, Morten@...e.de,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Bøgeskov <xen-users@...ten.bogeskov.dk>,
xfs@....sgi.com, xfs-masters@....sgi.com,
Mark Williamson <mark.williamson@...cam.ac.uk>
Subject: Re: Interaction between Xen and XFS: stray RW mappings
On Tue, Oct 23, 2007 at 10:36:41AM +1000, David Chinner wrote:
> > That doesn't mean it is correct.
>
> Right, but it also points to the fact that it's not causing problems
> from 99.999% of ppl out there.
So you're waiting for someone to take months to debug this again?
> You mean like vmap() could record the pages passed to it in the area->pages
> array,
The page tables contain pointers to the pages anyways. vunmap() has to walk
them. It would not be very difficult to store them in an array during
the walk.
>
> If we did this, it would probably be best to pass a page release function
> into the vmap or vunmap call - we'd need page_cache_release() called on
> the page rather than __free_page()....
Possible. Normally vmalloc pages should not be in the LRU except yours
so it would be probably fine to just change it.
> The solution belongs behind the vmap/vunmap interface, not in XFS....
You could also just keep the array from map time around yourself.
Then you could do it yourself.
-Andi
-
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