> It looks very much as if the mm being created has for pmd a page > which was used for user stack in the outgoing mm; but somehow exec's > exit_mmap TLB flushing hasn't taken effect. I only now noticed this > patch where you fix just such an issue.
Thanks for the analysis. However I doubt the load_cr3 patch can fix it. All it does is to stop the CPU from prefetching mappings (which can cause different problem). But the Linux code who does bad pmd checks never looks at CR3 anyways, it always uses the current->mm. If bad pmd sees a bad page it must be still in the page tables of the MM, not a stable TLB entry. It must be something else. Somehow we get a freed page into the page table hierarchy. After the initial 4level implementation I did not do many changes there, my suspection would be rather on the recent memory.c changes. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
