From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26806C28CC1 for ; Sat, 1 Jun 2019 13:34:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 013EB2750F for ; Sat, 1 Jun 2019 13:34:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559396049; bh=OTPTXRE+XDoW9UeWQydQqGzAVFJydQDHPoql3bTFqg8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=P0yTMHUIZeo8HOx72t1xRl90m9OwJLQXa3fZ+vSAS9zww9rLYi4KClhRyvsae0J4F 6ik7kxReckZzunmwhCBuodeJPNjKDPGpVrYMGXc6EO43aYTjCemhGOWBLJbSkd4Ayq 0KTrNE6WNm/9eeBgH00jGwtNR5ftxkX1gsVslOtk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728815AbfFANYI (ORCPT ); Sat, 1 Jun 2019 09:24:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:54110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727750AbfFANYH (ORCPT ); Sat, 1 Jun 2019 09:24:07 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 19B3D27333; Sat, 1 Jun 2019 13:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559395446; bh=OTPTXRE+XDoW9UeWQydQqGzAVFJydQDHPoql3bTFqg8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l8uMPua9iDbJeAqUpahIsFE7/Xg2SNRneCQXe2Wnac4KllaQqzqm0G391bPvNaFVb mUmpXvEIdCHRCfFzw30Io7t8QD5QmR6oiIU6I41keN/YnnSeoBuNAbfbvpEWcbAfd0 +PTi9Gxj2Oh+9rz/JkpE+Q6Yyy5C9om+Uwf+yOrI= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mike Kravetz , Naoya Horiguchi , Davidlohr Bueso , Joonsoo Kim , Michal Hocko , "Kirill A . Shutemov" , Andrew Morton , Linus Torvalds , Sasha Levin , linux-mm@kvack.org Subject: [PATCH AUTOSEL 4.14 07/99] hugetlbfs: on restore reserve error path retain subpool reservation Date: Sat, 1 Jun 2019 09:22:14 -0400 Message-Id: <20190601132346.26558-7-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190601132346.26558-1-sashal@kernel.org> References: <20190601132346.26558-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mike Kravetz [ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ] When a huge page is allocated, PagePrivate() is set if the allocation consumed a reservation. When freeing a huge page, PagePrivate is checked. If set, it indicates the reservation should be restored. PagePrivate being set at free huge page time mostly happens on error paths. When huge page reservations are created, a check is made to determine if the mapping is associated with an explicitly mounted filesystem. If so, pages are also reserved within the filesystem. The default action when freeing a huge page is to decrement the usage count in any associated explicitly mounted filesystem. However, if the reservation is to be restored the reservation/use count within the filesystem should not be decrementd. Otherwise, a subsequent page allocation and free for the same mapping location will cause the file filesystem usage to go 'negative'. Filesystem Size Used Avail Use% Mounted on nodev 4.0G -4.0M 4.1G - /opt/hugepool To fix, when freeing a huge page do not adjust filesystem usage if PagePrivate() is set to indicate the reservation should be restored. I did not cc stable as the problem has been around since reserves were added to hugetlbfs and nobody has noticed. Link: http://lkml.kernel.org/r/20190328234704.27083-2-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Cc: Davidlohr Bueso Cc: Joonsoo Kim Cc: Michal Hocko Cc: "Kirill A . Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- mm/hugetlb.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 64a62584290c4..584f089ac79b1 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1271,12 +1271,23 @@ void free_huge_page(struct page *page) ClearPagePrivate(page); /* - * A return code of zero implies that the subpool will be under its - * minimum size if the reservation is not restored after page is free. - * Therefore, force restore_reserve operation. + * If PagePrivate() was set on page, page allocation consumed a + * reservation. If the page was associated with a subpool, there + * would have been a page reserved in the subpool before allocation + * via hugepage_subpool_get_pages(). Since we are 'restoring' the + * reservtion, do not call hugepage_subpool_put_pages() as this will + * remove the reserved page from the subpool. */ - if (hugepage_subpool_put_pages(spool, 1) == 0) - restore_reserve = true; + if (!restore_reserve) { + /* + * A return code of zero implies that the subpool will be + * under its minimum size if the reservation is not restored + * after page is free. Therefore, force restore_reserve + * operation. + */ + if (hugepage_subpool_put_pages(spool, 1) == 0) + restore_reserve = true; + } spin_lock(&hugetlb_lock); clear_page_huge_active(page); -- 2.20.1