Re [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE for hugetlbfs

Re [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE for hugetlbfs

[Hushijie]

 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.