linux-kernel - Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <15eb1a2f-25f3-7d4a-e792-0b71bef6a720@oracle.com>
Date:   Thu, 20 Oct 2016 09:29:35 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Jan Stancek <jstancek@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
        Michal Hocko <mhocko@...e.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Hillf Danton <hillf.zj@...baba-inc.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private
 mapping error paths

On 10/20/2016 08:44 AM, Jan Stancek wrote:
> 
> 
> 
> 
> ----- Original Message -----
>> From: "Mike Kravetz" <mike.kravetz@...cle.com>
>> To: linux-mm@...ck.org, linux-kernel@...r.kernel.org
>> Cc: "Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>, "Naoya Horiguchi" <n-horiguchi@...jp.nec.com>, "Michal
>> Hocko" <mhocko@...e.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, "Hillf Danton"
>> <hillf.zj@...baba-inc.com>, "Dave Hansen" <dave.hansen@...ux.intel.com>, "Jan Stancek" <jstancek@...hat.com>, "Mike
>> Kravetz" <mike.kravetz@...cle.com>
>> Sent: Thursday, 20 October, 2016 5:11:16 AM
>> Subject: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths
>>
>> This issue was discovered by Jan Stancek as described in
>> https://lkml.kernel.org/r/57FF7BB4.1070202@redhat.com
>>
>> Error paths in hugetlb_cow() and hugetlb_no_page() do not properly clean
>> up reservation entries when freeing a newly allocated huge page.  This
>> issue was introduced with commit 67961f9db8c4 ("mm/hugetlb: fix huge page
>> reserve accounting for private mappings).  That commit uses the information
>> in private mapping reserve maps to determine if a reservation was already
>> consumed.  This is important in the case of hole punch and truncate as the
>> pages are released, but reservation entries are not restored.
>>
>> This patch restores the reserve entries in hugetlb_cow and hugetlb_no_page
>> such that reserve entries are consistent with the global reservation count.
>>
>> The huge page reservation code is quite hard to follow, and this patch
>> makes it even more complex.  One thought I had was to change the way
>> hole punch and truncate work so that private mapping pages are not thrown
>> away.  This would eliminate the need for this patch as well as 67961f9db8c4.
>> It would change the existing semantics (as seen by the user) in this area,
>> but I believe the documentation (man pages) say the behavior is unspecified.
>> This could be a future change as well as rewriting the existing reservation
>> code to make it easier to understand/maintain.  Thoughts?
>>
>> In any case, this patch addresses the immediate issue.
> 
> Mike,
> 
> Just to confirm, I ran this patch on my setup (without the patch from Aneesh)
> with libhugetlbfs testsuite in loop for several hours. There were no
> ENOMEM/OOM failures, I did not observe resv leak after it finished.

Thanks for the testing Jan.

I do not have access to a Power system, so I simulated the condition to
test.

-- 
Mike Kravetz

> 
> Regards,
> Jan
> 
>>
>> Mike Kravetz (1):
>>   mm/hugetlb: fix huge page reservation leak in private mapping error
>>     paths
>>
>>  mm/hugetlb.c | 66
>>  ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 66 insertions(+)
>>
>> --
>> 2.7.4
>>
>>