Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7075634ybi; Thu, 13 Jun 2019 09:09:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzuXZ0QtWC5Kxd4TSG5XFU67bL2e9Uko51GfYgMrghlNHUmVbPlHkSTZixJZR5pvHn0LMbA X-Received: by 2002:a17:90a:a601:: with SMTP id c1mr6191049pjq.24.1560442166509; Thu, 13 Jun 2019 09:09:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560442166; cv=none; d=google.com; s=arc-20160816; b=SCYlbVAlkqIOEAa0wIfe0ByphrcijlGa1v4UCZqAnMiQALGcF5iQNP4WW8cWNjT97g uNYra8/q1V01AoFGSrIKnKn7EhOi9d0AQJNB2VrXPREw6vuvXQrI7/Gl5UVg439byzFe 5gHOfi1vZ+KAL2WJMb67cubb06uE9CwLQ7WwVsIlVggyKfabd6+wIElooZJuj7CmE7XR XlbvAr0oBA0j1rECG+/df2xVukay/r8lm7tAUq+BCUI1D/MDD5EtKXPVH6vdCQc/t74v wlup8M52w/CSSmUJfyV4dz7vR1tYL57ynF27ILOJbt1CX7KYj6yOFBU43pxey2JnKlbe BbfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=hEeV/rcwPDaUPIlQaLk5gkWcUuCy1YYbl1ChlUGGVec=; b=pCOMKHnIrse4RSNC8qBhIE8CMv2VMfKloy8KcDIOJYCcRfzpeMGAnB27VKBiAM2v7Y M2vwX7dGzDg0xSw/lNYcj4t3fIJA7TErpdOlKpu1mV0OnswjaZcLWzxuoi/05P14Mh0q KcIRn7SF0BRvB6EHYe9L/+DCdqech/6U6iz+T4MaCGSwZjMnNGhrStGfoiKEtLcVqXkc 4aF/d7unUHtjsjJUFYwCUU8BYyxhHaF4ckkHvxk1x0zGhbdpcA0jfT5drruaOERTcA4l SJSlKZQetz3O5pNGCqcBGrf/q18swZkktw4DStWt/bRBGG+21NZIZUBgOrHCPx9j8cma kW2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="tYTin/SJ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j14si4277pfe.183.2019.06.13.09.09.11; Thu, 13 Jun 2019 09:09:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="tYTin/SJ"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391001AbfFMQIz (ORCPT + 99 others); Thu, 13 Jun 2019 12:08:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:33654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731271AbfFMIoy (ORCPT ); Thu, 13 Jun 2019 04:44:54 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F3829215EA; Thu, 13 Jun 2019 08:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560415493; bh=haeOm/iHF6Ymi2w3NIruSHvEIpq/d+b10TKv8Coa/hM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tYTin/SJPjnXwJ7yCVbbHvuBJwcvP86t0eXsHOGXQmx3xXHyfDTSjf0K8Wtg6jNMu ACIiYq4RMz61hX+dMb36iOrxHBQQN1RzMSNjpCK6rMVRLK9zpKuhA5rxIxNIBcq7Qz uRNvzlOOc90dIrabYrre1xsWGqVFXgVZD392aHiA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mike Kravetz , Naoya Horiguchi , Davidlohr Bueso , Joonsoo Kim , Michal Hocko , "Kirill A . Shutemov" , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 5.1 013/155] hugetlbfs: on restore reserve error path retain subpool reservation Date: Thu, 13 Jun 2019 10:32:05 +0200 Message-Id: <20190613075653.507415166@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190613075652.691765927@linuxfoundation.org> References: <20190613075652.691765927@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ 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 5baf1f00ad42..5b4f00be325d 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1258,12 +1258,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