On 08/14/2013 07:56 AM, Zhouping Liu wrote: > On 08/13/2013 09:29 PM, Stanislav Kholmanskikh wrote: >> >> On 08/06/2013 10:52 AM, Stanislav Kholmanskikh wrote: >>> 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++ > > Sorry for lately replying, as I'm a little busy these days... > > we all know (you have explained) VDSO vma is inserted by > install_special_mapping(), and the sysctl_max_map_count > don't check the special vma, that's the reason why map_count is to > became one greater than max_map_count,
The function install_special_mapping() __does__ increase mm->map_count. [vdso] is mapped one of the first vmas when a binary is executed so it's not a problem or bug that sysctl_max_map_count is not checked in install_special_mapping(). So we should not filter out [vdso] string from /proc/[pid]/maps (as we have in git test version). I mean that the reason why map_count could be one greater than max_map_count is not related to [vdso] or [vsyscall]. It's caused by the kernel test I posted above. Thanks. > > For vsyscall vma, a kernel developer ever told me that the vma is > never inserted into vma list, so sysctl_max_map_count > also don't check it. I don't verify it from kernel codes, but lots of > testing have proved it's right - sysctl_max_map_count didn't > check the two special vma VDSO and VSYSCALL. > > Depending on this, I think the previous codes is right, any comments? > > Thanks, > Zhouping ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. 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
