Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755336AbcKBDQV (ORCPT ); Tue, 1 Nov 2016 23:16:21 -0400 Received: from out0-156.mail.aliyun.com ([140.205.0.156]:56219 "EHLO out0-156.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752855AbcKBDQT (ORCPT ); Tue, 1 Nov 2016 23:16:19 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R301e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03305;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---.77iFHy9_1478056547; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Mike Kravetz'" , , Cc: "'Aneesh Kumar K . V'" , "'Naoya Horiguchi'" , "'Michal Hocko'" , "'Kirill A . Shutemov'" , "'Dave Hansen'" , "'Jan Stancek'" , , "'Andrew Morton'" References: <1476933077-23091-1-git-send-email-mike.kravetz@oracle.com> <1476933077-23091-2-git-send-email-mike.kravetz@oracle.com> In-Reply-To: Subject: Re: [PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths Date: Wed, 02 Nov 2016 11:15:47 +0800 Message-ID: <069501d234b7$68941380$39bc3a80$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCXAeF7CBWu9caWM/txVpIifxVeOAK10Lj0Aq8saoyjEEFukA== Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1892 Lines: 38 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