On Thu, Mar 15, 2012 at 01:16:28PM -0400, Dave Jones wrote: > On Thu, Mar 15, 2012 at 03:44:31PM +0100, Andrea Arcangeli wrote: > > > At some point prior to the panic, a "bad pmd ..." message similar to the > > following is logged on the console: > > > > mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7). > > Hmm, I wonder if this could explain some of the many bad page state bug > reports we've seen in Fedora recently. (See my recent mail to linux-mm) Yes. https://bugzilla.redhat.com/show_bug.cgi?id=747738 https://bugzilla.redhat.com/show_bug.cgi?id=766676 as found by Ulrich. > > Reported-by: Ulrich Obergfell <uobergfe@xxxxxxxxxx> > > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> > > Should probably go to stable too ? How far back does this bug go ? This goes back to 2.6.38 (included). After it gets a bit more of testing and reviews it'll be ok for stable yes. The fact MADV_DONTNEED zaps ptes with the mmap_sem in read mode frankly escaped me. Then there was some other hiccup in readonly walks that only hold the mmap_sem in read mode. memcg walk_page_range especially should be careful because whenever somebody does walk_page_range with the mmap_sem in read mode, the result is undefined, so those walks should be ok with the fact they're not accurate, if they need accuracy and full synchrony with the VM status they must take the mmap_sem in write mode before doing the walk_page_range (but that's not related to this race condition, it's just something I noticed and I wasn't sure if it was safe so I'm mentioning it here). For those paths walking pagetables with the mmap_sem hold for reading, MADV_DONTNEED can run simultaneously with other regular page faults, with transhuge page faults, with get_user_pages_fast secondary MMU faults all together. A pmd that is none can become regular, huge under the code that process it. A pmd that is huge can become none (because of MADV_DONTNEED). So to fix this it's enough to proceed doing the leaf level pte walk after checking the pmd is not none, and not huge in an atomic way. In short the crux of the fix is to add a barrier() and cache the pmd value in between the two checks so that we know a pmd is really stable and we can do the leaf pte level walk safely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>