On Tue, 2007-10-23 at 01:35 +0200, Andi Kleen wrote:
> On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
> > On Mon, Oct 22, 2007 at 09:07:40PM +0200, Andi Kleen wrote:
> > > On Mon, Oct 22, 2007 at 11:40:52AM -0700, Jeremy Fitzhardinge wrote:
> > > > Andi Kleen wrote:
> > > > > Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:
> > > > >
> > > > >> Yes, that's precisely the problem. xfs does delay the unmap, leaving
> > > > >> stray mappings, which upsets Xen.
> > > > >>
> > > > >
> > > > > Again it not just upsets Xen, keeping mappings to freed pages is
> > > > > wrong generally
> > > > > and violates the x86 (and likely others like PPC) architecture
> > > > > because it can
> > > > > cause illegal caching attribute aliases.
It is a serious offense to leave stray mappings for memory which can get
re-mapped to I/O devices... especially with PCI and other device
hotplug. I have to back up Andi on this one unconditionally.
On architectures where you have multibyte, non-wordsize updates to
hardware page tables, you even have races here when setting, updating
and clearing PTEs that must be done in a sequence where no aliasing of
mappings to partially written PTEs can result in I/O memory getting
mapped in a cacheable state. The window here is only one instruction,
and yes, it is possible for a window this small to create a problem. A
large (or permanently lazy) window is extremely frightening.
These things do cause bugs. The bugs take a very long time to show up
and are very difficult to track down, since they can basically cause
random behavior, such as hanging the machine or losing orbit and
crashing into the moon.
Zach
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home