From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A350252F26F; Wed, 30 Sep 2026 17:49:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790790549; cv=none; b=KLCNCk8VOpDeAryUfkxxsmjG01JyD+3WG0jg3ZS8GYv+rcokOAYNcfTn5/bRiwNZC5ws0SwTxIPBiEyQpw4jLDUkJZXagDqoddB8B1FIcNceRsETuqj/co4iH0L5D7JVrBjkk8ym0coGBiUydUH3R+4wscLYE4gHqvbjjK7Adkc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790790549; c=relaxed/simple; bh=DxAGJsw5Sw5oyGI4RT4kIbAWDwDaO+NbkrFR4jZZiQs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ls1Jzhye/F2BZbNwKOHDXa7rRF1/hOBxfYuDL24iKFTk6CJxNWUvS9EyeHhvFCxXL2BQG0jnrMvAGQK3rORZHeY1+GeU3DWM2mWv10BWVlD0PGV4S3DXgnsCrp8CJl0MD9fKoFPC7quo7E9mwV+TaJVHcHi3cOgmqEA4NEEqB6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=baYhyJjP; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="baYhyJjP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 128B01F000FF; Wed, 30 Sep 2026 17:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1790790548; bh=yQYb8LYDjn8uFv62n+rOnGBGdLL8Bq5Z1xWQskaFaOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=baYhyJjPFbk8wHv77xznO8lDrPKAls/xTuUxB4e3792GjKzrF7jFfaQkLrEXimLIT EidH4rAwUTjpdq6uhQUy8BTtWTDvNaqzmLdidr2O7HnYpi1tOLwT1xRvjA3l2k0W1w y7/RCdVcsEMgfxZ1DsIWEoOCfsY4g7NUe5Gnxy1c= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jinjiang Tu , David Hildenbrand , Oscar Salvador , Kefeng Wang , Muchun Song , Nanyong Sun , Andrew Morton , Sasha Levin Subject: [PATCH 6.12 831/877] mm/hugetlb: fix surplus pages in dissolve_free_huge_page() Date: Wed, 30 Sep 2026 17:29:02 +0200 Message-ID: <20260930152432.665237618@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260930152414.738996857@linuxfoundation.org> References: <20260930152414.738996857@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jinjiang Tu [ Upstream commit cb402bbdabcaa5a765068c5b8673bbfc1c264242 ] In dissolve_free_huge_page(), free huge pages are dissolved without adjusting surplus count. However, free huge pages may be accounted as surplus pages, and will lead to wrong surplus count. I reproduce this issue on qemu. The steps are: 1) Node1 is memory-less at first. Hot-add memory to node1 by executing the two commands in qemu monitor: object_add memory-backend-ram,id=mem1,size=1G device_add pc-dimm,id=dimm1,memdev=mem1,node=1 2) online one memory block of Node1 with： echo online_movable > /sys/devices/system/node/node1/memoryX/state 3) create 64 huge pages for node1 4) run a program to reserve (don't consume) all the huge pages 5) echo 0 > nr_huge_pages for node1. After this step, free huge pages in Node1 are surplus. 6) create 80 huge pages for node0 7) offline memory of node1, The memory range to offline contains the free surplus huge pages created in step3) ~ step5) echo offline > /sys/devices/system/node/node1/memoryX/state 8) kill the program in step 4) The result: Node0 Node1 total 80 0 free 80 0 surplus 0 61 To fix it, adjust surplus when destroying huge pages if the node has surplus pages in dissolve_free_hugetlb_folio(). The result with this patch: Node0 Node1 total 80 0 free 80 0 surplus 0 0 Link: https://lkml.kernel.org/r/20250304132106.2872754-1-tujinjiang@huawei.com Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Signed-off-by: Jinjiang Tu Acked-by: David Hildenbrand Acked-by: Oscar Salvador Cc: Jinjiang Tu Cc: Kefeng Wang Cc: Muchun Song Cc: Nanyong Sun Signed-off-by: Andrew Morton Stable-dep-of: a363c62a653c ("mm/hugetlb: do not dissolve gigantic pages without runtime support") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- mm/hugetlb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2201,6 +2201,8 @@ retry: if (!folio_ref_count(folio)) { struct hstate *h = folio_hstate(folio); + bool adjust_surplus = false; + if (!available_huge_pages(h)) goto out; @@ -2223,7 +2225,9 @@ retry: goto retry; } - remove_hugetlb_folio(h, folio, false); + if (h->surplus_huge_pages_node[folio_nid(folio)]) + adjust_surplus = true; + remove_hugetlb_folio(h, folio, adjust_surplus); h->max_huge_pages--; spin_unlock_irq(&hugetlb_lock); @@ -2243,7 +2247,7 @@ retry: rc = hugetlb_vmemmap_restore_folio(h, folio); if (rc) { spin_lock_irq(&hugetlb_lock); - add_hugetlb_folio(h, folio, false); + add_hugetlb_folio(h, folio, adjust_surplus); h->max_huge_pages++; goto out; }