> > 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; What is looks like an issue for me. Here is C code could be used as test-case: #include <errno.h> #include <stdio.h> #include <sys/mman.h> int main() { char buffer[1024]; unsigned long len = 1ULL << 46; while(len) { void *ptr = mmap(4096, len, 0, MAP_PRIVATE | MAP_ANONYMOUS , -1, 0); if (ptr == MAP_FAILED) { if (errno == EPERM) break; if (errno == ENOMEM) { len >>= 1; continue; } return -1; } } if (errno == EPERM) { printf("Test failed, you have wrong ret code EPERM\n"); sprintf(buffer, "cat /proc/%d/maps", getpid()); system(buffer); return -1; } return 0; } >> >> + if (addr < mmap_min_addr) >> + return false; >> + >> return (addr > DEFAULT_MAP_WINDOW) == (addr + len > DEFAULT_MAP_WINDOW); > > But is this one necessary? We do sanitze hint address before going to > get_unmapped_address AFAIR. > I’m agree, looks like I was trying to fix something that already fine. Thanks, Ilya