From patchwork Tue Oct 18 00:25:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rik van Riel X-Patchwork-Id: 13009737 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07967C433FE for ; Tue, 18 Oct 2022 00:25:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89B8E6B0072; Mon, 17 Oct 2022 20:25:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84B116B0075; Mon, 17 Oct 2022 20:25:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 739606B0078; Mon, 17 Oct 2022 20:25:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 653696B0072 for ; Mon, 17 Oct 2022 20:25:18 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 30D82C0EC4 for ; Tue, 18 Oct 2022 00:25:18 +0000 (UTC) X-FDA: 80032175916.11.34135A4 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf07.hostedemail.com (Postfix) with ESMTP id CBC764002D for ; Tue, 18 Oct 2022 00:25:16 +0000 (UTC) Received: from [2603:3005:d05:2b00:6e0b:84ff:fee2:98bb] (helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1okaPu-0003yC-18; Mon, 17 Oct 2022 20:25:10 -0400 Date: Mon, 17 Oct 2022 20:25:05 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, stable@kernel.org, Naoya Horiguchi , Glen McCready , Mike Kravetz , Muchun Song , Andrew Morton , kernel-team@meta.com Subject: [PATCH] mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages Message-ID: <20221017202505.0e6a4fcd@imladris.surriel.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=none; spf=none (imf07.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666052716; a=rsa-sha256; cv=none; b=0g60N/kUAezAb5o6z/dBa/y8Ae2JF+5qLronFKHj2qXpZ3tygpgK0v2frlb4Wn1/W5H/mj eezgtS2mHyab7pz4lyklJdqLUvnzWAdB783f8x2ndWKAK/rtP+fHkhagLGVCq9dYs0PNgL 567r4MloOKEqFhov1QyAviy7PMnHzpQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666052716; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=vY9DzTal4pLD+ONd59GnhyzBaZdNj686DyyQp70t9uA=; b=fPe4FDe6BgTRYV5c2JVsvtHLBsOTEKaMEOPGgphin6BsI9ESpmp+ZdZgvFoXB30MWUb0DE u4Lm0GAYpFEhpaXxAbVazMxWZhofaIx5EBjPYv/Toy3+w+71K3DgzuitUnbjMtN495mDp5 PvtILYUdDUqGVQLcnbzvmQKyXOwApy4= Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=none (imf07.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 9prayqywzkxjbjr58nbwntw75dchkyfr X-Rspamd-Queue-Id: CBC764002D X-HE-Tag: 1666052716-366856 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race. Fixes: a88c76954804 ("mm: hugetlb: fix hugepage memory leak caused by wrong reserve count") Cc: stable@kernel.org Cc: Naoya Horiguchi Cc: Glen McCready Cc: Mike Kravetz Cc: Muchun Song Cc: Andrew Morton Signed-off-by: Rik van Riel Reviewed-by: Mike Kravetz --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index b586cdd75930..dede0337c07c 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2924,11 +2924,11 @@ struct page *alloc_huge_page(struct vm_area_struct *vma, page = alloc_buddy_huge_page_with_mpol(h, vma, addr); if (!page) goto out_uncharge_cgroup; + spin_lock_irq(&hugetlb_lock); if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) { SetHPageRestoreReserve(page); h->resv_huge_pages--; } - spin_lock_irq(&hugetlb_lock); list_add(&page->lru, &h->hugepage_activelist); set_page_refcounted(page); /* Fall through */