On Thu, 1 May 2014, Srivatsa S. Bhat wrote: > > I tried to recall the *exact* steps that I had carried out when I first > hit the bug. I realized that I had actually used kexec to boot the new > kernel. I had originally booted into a 3.7.7 kernel that happens to be > on that machine, and then kexec()'ed 3.15-rc3 on it. And that had caused > the kernel crash. Fresh boots of 3.15-rc3, as well as kexec from 3.15+ > to itself, seems to be pretty robust and has never resulted in any bad > behavior (this is why I couldn't reproduce the issue earlier, since I was > doing fresh boots of 3.15-rc). > > So I tried the same recipe again (boot into 3.7.7 and kexec into 3.15-rc3+) > and I got totally random crashes so far, once in sys_kill and two times in > exit_mmap. So I guess the bug is in 3.7.x and probably 3.15-rc is fine after > all... I don't know if we can conclude the bug is in 3.7 rather than 3.15. I spent a little while yesterday looking at your register dumps, and applying scripts/decodecode to your Code lines. I did notice a pattern to the general protection faulting addresses, and the dumps you show today confirm that pattern (but with "1e000000" at the top instead of yesterday's "9e000000"). Sorry, I really cannot spend more time on this, but thought I should at least throw out my observation before moving on. Here I've simply grepped out the lines with the significant pattern (and at least one of these lines is essentially a repetition of the line before, value moved from one register to another with offset subtracted; oh, and that R12 line, "it" has been added on to the vsize acct_collect() already accumulated). RAX: 9e00000005f9e8fd RBX: 000000000000000b RCX: 0000000000000001 RAX: 9e00000005f9e5fd RBX: ffff881031a0c2f8 RCX: ffff88203d52ba40 RDX: 000000000000001e RSI: 9e00000005f9e5a5 RDI: ffff881031a0c2f8 R10: 0000000000000000 R11: 00000000000027d5 R12: 9e000000069d62fd BUG: Bad page map in process kdump pte:1e00000005f98701 pmd:1031489067 BUG: Bad page map in process kdump pte:1e00000005f98701 pmd:103420b067 R13: 0000000000000004 R14: 1e00000005f93403 R15: 000000000000000a That this corruption likes to attack mm structures (vmas yesterday, page tables today) does make me wonder whether mm is to blame. Hugh -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>