On 4/28/20 6:46 AM, Mike Kravetz wrote: >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. >The routine hugetlb_get_unmapped_area has not changed much since this first >git version. I suspect this is because it is mostly unused. > >I noticed that hugetlb_get_unmapped_area is one of only a few places in arch >independent code calling vm_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 calling vm_unmapped_area >directly? 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.
