From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (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 970D53EDACD for ; Fri, 15 May 2026 21:44:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778881462; cv=none; b=pX8J2qN4iq/+Yp7ZgWD3INZtT5GG2Tvg8vgV0+FCiSLwDCt89dsQaObKNqbBtI5Z80npNRfdtmPn09VO6O4fGCAuztdwqX+TJiq/q2BiY1bZl3D646tnYf5X0E/AfVU6B8IpGtIMbZEF7vPiA4RkVzVl5XtIztC3aC/bxct6KvE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778881462; c=relaxed/simple; bh=An5D9p+EUiNzuq65UFLmP+yFhJds1Oq2E/WMsv+uYmA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OhjRywOpKYOxykmPdwLz6C0PIkxUpUoGf/N+o6ZQX2GeaG/hzyMooio0sBn2SrF/HPY0kFsADJ7ccllHyJTLcqZiIQEAeoGb0LNmbOM5fefSHdP+75xGfAVifSj0UJG5sqFb5NhLnvz6XEGWRc+1m59dbYw8hQc7LPP3suL/By4= 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=QkEXh7M5; arc=none smtp.client-ip=74.125.224.54 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="QkEXh7M5" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-6579254f996so462993d50.1 for ; Fri, 15 May 2026 14:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778881461; x=1779486261; 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=kI2tbQ3gv/rOPLpkzmuHjc3hm2p0ykSJGbw2DjymBGE=; b=QkEXh7M50fKvXpfKRL/LAQmfuV0uT1VEPiQb67BSIYxo937UfJz9IEYNbh431bH/vm FgXViwWR0zJYh7i4A+aMe40vKt3NR2jf2k/BrF+oeF9DeDvS8Lu16wfJ6jCkEfIpEg/F ZrjSXmOxkdnVmmJJ9ShooWeqCsN4Bp2xOM6a3fcwKEaeguH0z4HrblHwAmgdF85hr53P 62SAeYVQEsocX3NCilxE2TejiUOVTk6MemoroaVigdDwNbragbdLZg9oJfH7W5FDheNP P6GAgozzyhf+mWzj0PEvCjI9jAXIZYhSakxaT37uPHrejLrOro5CHFYyR/5w4RiXBKGN XTzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778881461; x=1779486261; 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=kI2tbQ3gv/rOPLpkzmuHjc3hm2p0ykSJGbw2DjymBGE=; b=b1iacZE0YCtXzglhyjlERZH/2/uszTP6fCytVZlnOUq0bO6tcbagfambyBcJdc1v+1 LWScwerLuxGzlDaEK6chLzqnqCe8HIV+0M4jWizvbHQpP10rU28cieYg3189FClM/s5E wgcBrboryHySw45k7SOqeWUHLx+W42ft8R9fAa0wh//cddOk7dReiD/ZpvqDn57KTURq xfHiuFt//Kz7tuIUJLlKIfJUr5z4RAtk+lpm4BylKo/y0WT2GKQQT7Vz/UOMZUU1vXjI momiWzY+JYz/Dc4b4oxNI6LlM15gKIP2Q6oy09cdOz6VQSr4HQbBdq69xByqt5X7GUDz y5CQ== X-Forwarded-Encrypted: i=1; AFNElJ+Q+s6iG/AKKclMonpku5TAy4LW3cHr2m3CHGL7BM4iShoBjY6AlGg+onTAnsLdP65vI76M1uhwTELVfRw=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1BSCTtJSl7OfSz9eyNt9pNPqFnoUQFQpvgmeZ1xvAUGFzzjSs cgUfFAmjzci3OWxuXASmnJ9k5iRlr9k3Sp8Q3N7xejgIhovLTOlugnyJ X-Gm-Gg: Acq92OFFXLVKzSIcBelaSfn/OIkNvrSsxM8lUqF6i9JkkEpElb7jhs3c29WF3UmECLK sMpky+YA2EUM44qFSuaRYgVqbLr8fr1DzTQXPYYrtXflLyft1pqkpF1mB/k/93wpiP4voUYjvu+ YxfinIvzv7SnUwrx1krx0JYSeFm6LEyEQTpczrC/vWgiwh0KInlCmLHBB73KjOr6vPv4dU1sjGR yLYzB35lFdLM0DTNNeL6dYbYwRb8XYziyHd57Rc/SGqO5fvK/CUJ5RWf5RqgUB7BJSbdjzcB6wv xKvibeVdbFWFl4XVEahhoK0tJpYvongJDEhXErov/BhwJWIJ/yWbvhSVht5T1PZg48iwG04H/xo 9iIypoBhPwTbTP9DzXJABmsH+KNTuzmaK7Rh6r5R4LV+GGcEr69cPB6X/BVImDcn2aEj2byaLVV KpZR2orinFxoKW5zrsp2qW7T9j/pkSWVS17PfAzB4oFrXhPCdPPA5UxypGJeGJjUc= X-Received: by 2002:a05:690c:c513:b0:7b3:9f53:9374 with SMTP id 00721157ae682-7c959e88e51mr72446817b3.3.1778881460615; Fri, 15 May 2026 14:44:20 -0700 (PDT) Received: from localhost ([2a03:2880:f806:c::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7c92e2e978fsm22034177b3.24.2026.05.15.14.44.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 14:44:20 -0700 (PDT) From: Joshua Hahn To: David Carlier Cc: akpm@linux-foundation.org, linux-mm@kvack.org, muchun.song@linux.dev, osalvador@suse.de, david@kernel.org, joshua.hahnjy@gmail.com, mawupeng1@huawei.com, stable@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/hugetlb: restore subpool used_hpages on alloc_hugetlb_folio error Date: Fri, 15 May 2026 14:44:18 -0700 Message-ID: <20260515214418.3259977-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260515202902.461539-1-devnexen@gmail.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Fri, 15 May 2026 21:29:02 +0100 David Carlier wrote: > Commit a833a693a490 added a !gbl_chg guard around the > hugepage_subpool_put_pages() call in alloc_hugetlb_folio()'s > out_subpool_put path so a failed allocation wouldn't drive > h->resv_huge_pages negative. But hugepage_subpool_get_pages() > increments spool->used_hpages whenever max_hpages != -1, regardless > of whether the request was satisfied from subpool reserves or needs > global pages. When gbl_chg > 0 and a later step fails (cgroup > charge, dequeue, buddy alloc), used_hpages is never put back. > > Each such failure leaks one count; eventually used_hpages reaches > max_hpages and the subpool refuses every further allocation even > though no pages are held. > > Commit 1d3f9bb4c8af fixed the same defect in hugetlb_reserve_pages(); > apply the equivalent restore here, guarded by spool and max_hpages. Hello David, Thank you for the patch! I noticed that this patch is quite similar to Zhao Li's patch [1] which seems to address the same problem. Have you taken a look at his approach? >From what I can tell, the code change is also quite similar (except comments and additional guards in the else if branch). Just wanted to bring it to your attention in case you haven't seen it yet. Have a great day! Joshua [1] https://lore.kernel.org/linux-mm/20260428114126.92091-2-enderaoelyther@gmail.com/ > Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") > Signed-off-by: David Carlier > Cc: Joshua Hahn > Cc: Wupeng Ma > Cc: Oscar Salvador > Cc: Muchun Song > Cc: David Hildenbrand > Cc: > --- > mm/hugetlb.c | 19 ++++++++++++++++--- > 1 file changed, 16 insertions(+), 3 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index cfb7cb2e9806..9614330889de 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -3010,9 +3010,22 @@ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, > * put page to subpool iff the quota of subpool's rsv_hpages is used > * during hugepage_subpool_get_pages. > */ > - if (map_chg && !gbl_chg) { > - gbl_reserve = hugepage_subpool_put_pages(spool, 1); > - hugetlb_acct_memory(h, -gbl_reserve); > + if (map_chg) { > + /* > + * Put used_hpages back for the global portion of the request that > + * was never actually consumed; restore the subpool-reservation > + * portion via hugepage_subpool_put_pages() so rsv_hpages is rebuilt. > + */ > + if (!gbl_chg) { > + gbl_reserve = hugepage_subpool_put_pages(spool, 1); > + hugetlb_acct_memory(h, -gbl_reserve); > + } else if (spool && spool->max_hpages != -1) { > + unsigned long flags; > + > + spin_lock_irqsave(&spool->lock, flags); > + spool->used_hpages -= 1; > + unlock_or_release_subpool(spool, flags); > + } > } > > > -- > 2.53.0