On Fri, Feb 3, 2012 at 3:10 AM, KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx> wrote: >> extern unsigned long move_page_tables(struct vm_area_struct *vma, >> diff --git a/mm/mmap.c b/mm/mmap.c >> index 3f758c7..2f9f540 100644 >> --- a/mm/mmap.c >> +++ b/mm/mmap.c >> @@ -992,6 +992,9 @@ unsigned long do_mmap_pgoff(struct file *file, >> unsigned long addr, >> vm_flags = calc_vm_prot_bits(prot) | calc_vm_flag_bits(flags) | >> mm->def_flags | VM_MAYREAD | VM_MAYWRITE | >> VM_MAYEXEC; >> >> + if (flags& MAP_STACK) >> + vm_flags |= VM_STACK_FLAGS; > > > ?? > MAP_STACK doesn't mean auto stack expansion. Why do you turn on > VM_GROWSDOWN? > Seems incorrect. > Right now MAP_STACK does not mean anything since it is ignored. The intention of this behaviour change is to make MAP_STACK mean that the map is going to be used as a stack and hence, set it up like a stack ought to be. I could not really think of a valid case for fixed size stacks; it looks like a limitation in the pthread implementation in glibc rather than a feature. So this patch will actually result in uniform behaviour across threads when it comes to stacks. This does change vm accounting since thread stacks were earlier accounted as anon memory. -- Siddhesh Poyarekar http://siddhesh.in -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
