linux-kernel - Re [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2f7fcfd8d66d4df7ac0c972fd9c3abc1@huawei.com>
Date:   Tue, 28 Apr 2020 11:49:32 +0000
From:   Hushijie <hushijie3@...wei.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nixiaoming <nixiaoming@...wei.com>,
        "wangxu (AE)" <wangxu72@...wei.com>,
        "Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@...wei.com>,
        yangerkun <yangerkun@...wei.com>,
        "Wangle (RTOS FAE)" <wangle6@...wei.com>,
        "Chengang (L)" <cg.chen@...wei.com>
Subject: Re [PATCH] [RFC]hugetlbfs: Get unmapped area below TASK_UNMAPPED_BASE
 for hugetlbfs

 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.