Re [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE for hugetlbfs
Quoted 5 lines · Mike Kravetz
Just curious. Have you actually seeing a problem with this code, or is the reason for the proposed change just the result of code inspection? I ask because many architectures have their own version of
hugetlb_get_unmapped_area. So, if you are seeing this issue it would be interesting to know what architecture you are running.
Thanks for your reply.
We actually found this problem on arm64 architecture, running a 32-bit program. When the address space below TASK_UNMAPPED_BASE is completely exhausted, shmat() for huge pages will return ENOMEM, but shmat() for normal pages can still success.
Quoted 9 lines
The routine
hugetlb_get_unmapped_areahas not changed much since this first git version. I suspect this is because it is mostly unused.I noticed that
hugetlb_get_unmapped_areais one of only a few places in arch independent code callingvm_unmapped_area(). The other callers are arch independent fall back routines for arch_get_unmapped_area* routines. If we move forward with changes to this routine, would it make more sense to use the arch_get_unmapped_area* routines instead of callingvm_unmapped_areadirectly? This would take advantage of any arch specific if it exists.
I totally agree with you.
It is more appropriate to implementing hugetlb_get_unmapped_area() for a specific architecture, instead of chaging common hugetlb_get_unmapped_area() interface at "fs/hugetlbfs/inode.c".
I will submit another patch just for specific architectures (arm64) later. Thanks for your reply and advise.