On Sun, 9 May 2010, Linus Torvalds wrote: > > Also - the thing is, we can easily choose to do this _just_ for the case > of shifting argument pages, which really is a special case (the generic > case of "mremap()" is a lot more complicated, and doesn't have the issue > with rmap because it's doing all the "new vma" setup etc). Looking at the stack setup code, we have other things we probably might want to look at. For example, we do that "mprotect_fixup()" to fix up possible vm_flags issues (notably whether execute bit is set or not), and that's absolutely something that we probably should do at the same time as moving the stack, so that we don't end up walking - and changing - the page tables _twice_. So the stack setup really is a total special case, and it looks like we do some rather stupid things there. Havign a specialized routine that does just: - if we're moving things, fill in the new page tables (we know they are dense, so my "stupid" routine actually does the right thing despite being pretty simplistic) before moving. - if we're moving _or_ changing protections, do a for_each_page() move_andor_fix_protection() which kind of looks like the current "move_page_tables()", except we know it doesn't need new allocations. Hmm? Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>