----- Original Message ----- > On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote: > > In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while > > holding > > the mmap_sem for reading, cmpxchg8b cannot be used to read pmd > > contents under Xen. > > > > So instead of dealing only with "consistent" pmdvals in > > pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually > > simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with > > pmdvals > > where the low 32bit and high 32bit could be inconsistent (to avoid > > having to use cmpxchg8b). > > <nods> > > > > The only guarantee we get from pmd_read_atomic is that if the low > > part > > of the pmd was found null, the high part will be null too (so the > > pmd > > will be considered unstable). And if the low part of the pmd is > > found > > "stable" later, then it means the whole pmd was read atomically > > (because after a pmd is stable, neither MADV_DONTNEED nor page > > faults > > can alter it anymore, and we read the high part after the low > > part). > > > > In the 32bit PAE x86 case, it is enough to read the low part of the > > pmdval atomically to declare the pmd as "stable" and that's true > > for > > THP and no THP, furthermore in the THP case we also have a > > barrier() > > that will prevent any inconsistent pmdvals to be cached by a later > > re-read of the *pmd. > > Nice. Andrew, any chane you could test this patch on the affected > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?) > hypervisor or is it really only on Linode and Amazon EC2? >
Originally, I was able to reproduce the issue easily with a RHEL5 host. Now, with this patch it's fixed. Drew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org