From nobody Sun Feb 8 11:06:37 2026 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) (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 68B482EBB8A for ; Fri, 16 Jan 2026 20:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768596040; cv=none; b=YK9io4PqeVrQYdCRI9MbDOQbc6S02284iT3t7ZoKFqXZFc7m0N0im9aa+f7IHumn5HVLOTLmXRWrlcES83pUCpF+awWOn6tWLVvnYlc9PyHvuFJMJZqFww6UWyRcOUlIQwpN5iY3KFH6HpF9exk8knQfWzKPuBoyHxW56u5Je94= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768596040; c=relaxed/simple; bh=F9y/hUlElgS4/q5TL+nwejP7LZRYllGQ+bR8klfBFc4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=maENz9OsxojpB69tq6Zrhc1jl1FR2qyGu0eeWR8tqFB7qq/NuqOfaMvJkqT/68+XXGg3OxsFmi5f4Q5AEXAeFcqRU1UYVyBFGKrUGYWT7DWNWQ/4DWP2IQYDiP13nYst7gGGnwxCgw6HQ6Z7oWS20pcJfWNNEUmU4jQbKw1QrmQ= 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=d0FA/kil; arc=none smtp.client-ip=209.85.128.174 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="d0FA/kil" Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-78fba1a1b1eso39839167b3.1 for ; Fri, 16 Jan 2026 12:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768596038; x=1769200838; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=plLru19BPw4Gzl5/9w7riKopb0P86akIwhjnuskNV1s=; b=d0FA/kilqJCsYv7zaqQ/DF9QXT/eIxuDpqa0Bgc/1tlwQ0jMgR53oXqRPXGLcOCqXJ ajV2gwh6IUcllzawrA03I5x6F0u6QfppbK32qusRSyHIH1zCV45P9n+9DalMMIh+FpsO YCY0DyF8VGl2MZQSh4+QaxhkAF+83743/R/riG3D69F3M0fcxPcm0tk5w9MioibTAhmK +yjyfjD2yiCehVntU//YLsEColGNKy6Lso3/UT91Zq2Kc3e8hRneYDUo6xDp1iEbZhko lqsj0gWt4uVfsOkHtxRqO+/0ANjUwNFZBPX6PcF+LolHrBVIY1/qHzofAqUX3V4xDpvy HwaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768596038; x=1769200838; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=plLru19BPw4Gzl5/9w7riKopb0P86akIwhjnuskNV1s=; b=R5pC+u9LtkikLnB1/SPb0MAmUDyUj8PniyR079WI8QCWfUxdErAqL7oegFnJFuhwVs KZReIT48Bt99yXCTU6hNoyOdYuDnz5S8q22zJu9kJqqdTbdHK4eshwmWNZupKyk2mEoQ W4Ee+m0nbdiwZklPEA6/TIJPL6IBzdb8DFaPmbbb64T4Rt1CPlSHi0GzDfsHL72bS/Oc QuEsJxR04ZUMbB9DQ3p28Huw5KoRAeIVihGwy1+LBiUy8kFbRxgaduHWCuuZFdFAaxPj Z5pN4/+xqKv2WwT3ek8dITxaP6EXuZ9OjOuv/mCKdU/18j+gLOJuix8E7hOXg+Iec1I/ GuSw== X-Forwarded-Encrypted: i=1; AJvYcCUr1dp6/027hZrCjK+HapqhN3khEGwNDpE1O5YN6hNDF138TZ3wVuUfSBR1BBfCpPFOPuIdclCk0i2Oew0=@vger.kernel.org X-Gm-Message-State: AOJu0YwcaDKk02gFjkI19KKeV/0rQCzJDoSrZbB5/EqgJhyznbM8rcK4 5Ww+5hz6A8g8DLA2J+o+wY+pKsyNt3eeERSEoZupkHhzkWCk4xq2/tmu X-Gm-Gg: AY/fxX6tBpJxfAMfQRfx1MbOcg3+UaJoq0tKKBkyuCvoagJKsGqthUAy+pSrSs12Wa2 e0fm7cnI6M6+04Uce8shgWlrEjmig/h4IdytZu2qJS8jbyJQZnitZmJCw4FhZPkmsES9lyHn43i P/Cbz5I91BjtDZ8BrqbyF8K9+fNGHZOkM2jgbty9BF36BeaL4jIs3J+rRjhv0rAj8Ztq28BE8Bc hTQ37NIXWZ9c2ibDfZLzPsLOxO2cHhqAt7hFM3kVUEFPQD0ci9rKMW+H/IRODb3TcOlOKUoqOHv gCWBWeBA1EGhOuyFMgtpVHerbMsAVX+2QfT3tguxjHP8luUrR+qqwGaciAxuXtr9xsAvdE7oG1W 7AgkOIQHxskV17EHyfCckwwVVtRRmzCzBWvoM9ukVDAa86rIQyWqNceKOUVAJ98+ucQddQixbyG 2TPRjuWyazAg== X-Received: by 2002:a05:690c:10d:b0:793:c7df:9dd5 with SMTP id 00721157ae682-793c7df9e51mr26768467b3.33.1768596038285; Fri, 16 Jan 2026 12:40:38 -0800 (PST) Received: from localhost ([2a03:2880:25ff:51::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-793c66c72bcsm13184287b3.2.2026.01.16.12.40.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jan 2026 12:40:37 -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, stable@vger.kernel.org, kernel-team@meta.com Subject: [PATCH v2] mm/hugetlb: Restore failed global reservations to subpool Date: Fri, 16 Jan 2026 15:40:36 -0500 Message-ID: <20260116204037.2270096-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 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 the original commit 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 --- v1 --> v2 - Moved "unsigned long flags" definition into the if statement it is used in - Separated fix patch from cleanup patches for easier backporting for stabl= e. mm/hugetlb.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 5a147026633f..e48ff0c771f8 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6713,6 +6713,15 @@ 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) { + unsigned long flags; + + 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); base-commit: c1a60bf0f6df5c8a6cb6840a0d2fb0e9caf9f7cc --=20 2.47.3