On Tue 27-02-18 16:27:29, Ilya Smith wrote: > > > > mmap_min_addr handling is a bit mess... As you say, we would return > > EPERM rather than ENOMEM which can be confusing but depleting the > > address space like that is quite unlikely on 64b unless I am missing. > > It is good to be in sync here with the generic implementation though, > > IMO. > > > > If we take a look on mm/mmap.c: > #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN > unsigned long > arch_get_unmapped_area_topdown( > … > if (len > TASK_SIZE - mmap_min_addr) > return -ENOMEM; > … > info.low_limit = max(PAGE_SIZE, mmap_min_addr); > > And this one looks like a generic implementation. > But for many other architectures like arch/parisc/kernel/sys_parisc.c > or arch/x86/kernel/sys_x86_64.c > > info.low_limit = PAGE_SIZE;
Yeah, this is what I meant when saying that mmap_min_addr is a bit of a mess. I am wondering whether the low_limit should be checked inside vm_unmapped_area. We would still need some mmap_min_addr handling at arch_get_unmapped_area_topdown layer which is still suboptimal but I do not see an easy way around without reworking how the arch specific parts are implemented currently. -- Michal Hocko SUSE Labs
