linux-kernel - Re: [PATCH 1/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] [day] [month] [year] [list]

Message-ID: <069501d234b7$68941380$39bc3a80$@alibaba-inc.com>
Date:   Wed, 02 Nov 2016 11:15:47 +0800
From:   "Hillf Danton" <hillf.zj@...baba-inc.com>
To:     "'Mike Kravetz'" <mike.kravetz@...cle.com>, <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>,
        "'Dave Hansen'" <dave.hansen@...ux.intel.com>,
        "'Jan Stancek'" <jstancek@...hat.com>, <stable@...r.kernel.org>,
        "'Andrew Morton'" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

On Wednesday, November 02, 2016 12:37 AM Mike Kravetz wrote:
> On 10/19/2016 08:11 PM, Mike Kravetz wrote:
> > Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly
> > allocated huge page.  If a reservation was associated with the huge
> > page, alloc_huge_page() consumed the reservation while allocating.
> > When the newly allocated page is freed in free_huge_page(), it will
> > increment the global reservation count.  However, the reservation entry
> > in the reserve map will remain.  This is not an issue for shared
> > mappings as the entry in the reserve map indicates a reservation exists.
> > But, an entry in a private mapping reserve map indicates the reservation
> > was consumed and no longer exists.  This results in an inconsistency
> > between the reserve map and the global reservation count.  This 'leaks'
> > a reserved huge page.
> >
> > Create a new routine restore_reserve_on_error() to restore the reserve
> > entry in these specific error paths.  This routine makes use of a new
> > function vma_add_reservation() which will add a reserve entry for a
> > specific address/page.
> >
> > In general, these error paths were rarely (if ever) taken on most
> > architectures.  However, powerpc contained arch specific code that
> > that resulted in an extra fault and execution of these error paths
> > on all private mappings.
> >
> > Fixes: 67961f9db8c4 ("mm/hugetlb: fix huge page reserve accounting for private mappings)
> >
> 
> Any additional comments on this?
> 
> It does address a regression with private mappings that appears to only be
> visible on powerpc.  Aneesh submitted a patch to workaround the issue on
> powerpc that is in mmotm/linux-next (71271479df7e/955f9aa468e0).  Aneesh's
> patch makes the symptoms go away.  This patch addresses root cause.
> 
Both works are needed, thanks.

Acked-by: Hillf Danton <hillf.zj@...baba-inc.com>