On 08/05/2013 07:41 PM, [email protected] wrote: > Hi! Hi, Cyril. >> * kernel test for max_map_count_sysctl is: >> /* Too many mappings? */ >> if (mm->map_count > sysctl_max_map_count) >> return -ENOMEM; > Hmm, that looks like we allow the map_count to became one greater than > max_map_count, is this known bug? I'm not sure whether this is a bug or feature but in fact mm/mmap.c contains this strict condition.
> >> so in LTP test map_count should be greater than max_map_count by 1 >> >> * only [vsyscall] is allocated without incrementing mm->map_count > That also looks strange, do you know why one is allocated without > incrementing it and another with? > [vdso] is allocated this way: 1) load_elf_binary (fs/binfmt_elf.c) 2) arch_setup_additional_pages (arch/x86/vdso/vdso32-setup.c) 3) install_special_mapping (mm/mmap.c) 4) insert_vm_struct (mm/mmap.c) 5) vma_link (mm/mmap.c) increases mm->map_count++ I've not found where [vsyscall] may increment map_count.... Maybe it's by design. As I understand [vsyscall] was initially and intentionally implemented as a 'hack' - mapping functions directly to process memory space. On the other side [vdso], which is an elf object, and should be inserted in a similiar way as all shared libraries do. IMHO. And manual testing approves the assumption that [vdso] increments and [vsyscall] - doesn't. Thank you. ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
