From nobody Mon Feb 9 17:35:47 2026 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F11D53E0B for ; Thu, 15 Jan 2026 18:14:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768500885; cv=none; b=U2o99gIhgNlGfInelfkI7cypp4RB+FDiKTNDEmq3hUyT3glFQMtBqT2CjRH7GgSpe2xEotd845FSZfDdr/fzfCZx87ohVqrfonktxwC6ZXVmNz8PLX+JvdipiaDm0V2WhgIWof+vtQ8kdcMaP66oxUVg4PfnKYanyh8Yo+jIfUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768500885; c=relaxed/simple; bh=PREq6X5dQOSijb3j/ArhlfPtqTgBVODvVTzNWDj0g6k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GcUyC/qa10cShD67NFISzzus1fyLuEsZJWILKPhvAJHB8xVXhdtc2xVSrJrA3XXeINGnd/6mvFKo2vJFMC7V38c0DQwr+k+yMFrpp3cvB0jCDE7AIwV+Dy3WeYIopjkj0hQ1hu5QBraovTYKGH96jd3g0CAgwfechuWrpNcY054= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a8vmqupj; arc=none smtp.client-ip=74.125.224.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a8vmqupj" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-6466d8fd383so1146089d50.2 for ; Thu, 15 Jan 2026 10:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768500882; x=1769105682; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=O45eLppLOCW6F7IMGZ1ULnrc2pXJxucNBG4tS3sUSSc=; b=a8vmqupjyGIDJlTY507dJkMjzIUVbErDhw3jbY26KNZAheovldgoxv3L+KdZOsVReo K1rlcFtOlI43v88vXKgpNfQPoTEizva0+EDP9Eej5WqVjVMn8aIa1NPL4Y3J3jGx1tzp BlBXNnuk9Hl4/1ig+yuXnxpST7JiM+37MluLX/0rZfslqIt1+lAu39AgseOSAriwAw6B pe5ji1DBhWW23VwbO+YeMnyilevkdk1mBdqnnXsVV3skZpsghpzfIqZS6FNR0q5Kdm8h dPK0Xy5E7PhdmDDm8144GB12TxppcESy69YjlD1x2c81sobru2Vi3hx/LNr+cSqvVKik JDLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768500882; x=1769105682; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=O45eLppLOCW6F7IMGZ1ULnrc2pXJxucNBG4tS3sUSSc=; b=RFe1c+xj3wrhiuKc/QUEBm1hJCmAD9nsmGBsEVV1rp5ao7eYC6jbbcgAbMQ7gwX12y sNqCMQWsNg6aQBpXw771u5tEdqM48cAaRhTUFGBtojJ9SsyVaeLWMWsVK53Th2U10wFP nvjx0ZOUc6gTiOSNhhZspqQjSVNt+d4ZYP8ynqPqh2os/SSDQz9tJP86xyjZeeOy9wQV OnMcguLRdHCqzPlLdvqak9wUhMX//zV9Pl0ztGhTpams6AUO7eQisojAD5P17iEa8DYS w18zjPuOJGZptcDbg9cAh7yG5Pfnzn2T6E+WZOCtIoW0Vv+/6DmO42Ye+a0ww+qB8f5H 57Wg== X-Forwarded-Encrypted: i=1; AJvYcCVzSjdqGQF2aYb3tTp7lz0QCGLakMhKAfNPo8GJeFy0q49JDiFPpAjngCxs+bPFHb7pMg9HVc46485Ty5A=@vger.kernel.org X-Gm-Message-State: AOJu0YxZUsvMJyYpeLYIpcYsWgFbv2/eU20lj0p0Tiz50QD6KdU/rolb HlNX2S43U+as6qpLwnL00X6MPNCJ8cx6Sr+MVAwb23NrZmLxiSu+KLObg/O7yw== X-Gm-Gg: AY/fxX4jq/ymRAcsp7nAdBJQKFLHYArVZzZIbBfw5K/o62k0PcPHhI/zdSDfkb9WMlM CMxbkfm7By07wIilKxRZxclEBTrK6Bs260rKtmZKuSa4BJtUpD0mT9fBFd9kd3JEtfBJqPnIPCf FxWqYb6pkUCjRoEZIuu3UUd7M3hvL+AN8NjR9AOV1cEajSID0+8INAiDXljAoFJF/INYD7YRMHO qYI+o2m95XUJBllbo3yXI+q3rKz6RwkPrvvjidygsfecdhoGt9zBN6Q6iXVri7zLUkX5zBUElAm pNMj+wg32Sd4jTfwTGgna7V0nejAho+h/Z9iAbgTVMo99DTU2wjewWWwRaZbcFlHzgRW6FzDIAT wM4UusRzGr8F2nn1ke5Y9mgrzRSngXtnzszKj6AHm1JCNadk6nGyfdZG3EvlEQrtzpNTR4J9lRR fYOGh0JD7g7c0MlyI/iPji X-Received: by 2002:a05:690e:b46:b0:63f:b634:4224 with SMTP id 956f58d0204a3-64916484f7bmr462440d50.21.1768500881797; Thu, 15 Jan 2026 10:14:41 -0800 (PST) Received: from localhost ([2a03:2880:25ff:44::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-793c68307b5sm98567b3.32.2026.01.15.10.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 10:14:41 -0800 (PST) From: Joshua Hahn To: Andrew Morton Cc: David Hildenbrand , Muchun Song , Oscar Salvador , Wupeng Ma , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, stable@vger.kernel.org Subject: [PATCH 1/3] mm/hugetlb: Restore failed global reservations to subpool Date: Thu, 15 Jan 2026 13:14:35 -0500 Message-ID: <20260115181438.223620-2-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260115181438.223620-1-joshua.hahnjy@gmail.com> References: <20260115181438.223620-1-joshua.hahnjy@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=3D4, min=3D2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages +=3D 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -=3D 2 5. Subpool now has used_hpages =3D 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. Repeating this process will ultimately render the subpool unable to allocate any hugepages, since it believes that it is using the maximum number of hugepages that the subpool has been allotted. The underflow issue that commit a833a693a490 fixes still remains fixed as well. Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") Signed-off-by: Joshua Hahn Cc: stable@vger.kernel.org --- mm/hugetlb.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 2e296d30a8d7..88b9e997c9da 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6560,6 +6560,7 @@ long hugetlb_reserve_pages(struct inode *inode, struct resv_map *resv_map; struct hugetlb_cgroup *h_cg =3D NULL; long gbl_reserve, regions_needed =3D 0; + unsigned long flags; int err; =20 /* This should never happen */ @@ -6704,6 +6705,13 @@ long hugetlb_reserve_pages(struct inode *inode, */ hugetlb_acct_memory(h, -gbl_resv); } + /* Restore used_hpages for pages that failed global reservation */ + if (gbl_reserve && spool) { + spin_lock_irqsave(&spool->lock, flags); + if (spool->max_hpages !=3D -1) + spool->used_hpages -=3D gbl_reserve; + unlock_or_release_subpool(spool, flags); + } out_uncharge_cgroup: hugetlb_cgroup_uncharge_cgroup_rsvd(hstate_index(h), chg * pages_per_huge_page(h), h_cg); --=20 2.47.3