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 5185A370D5E for ; Fri, 14 Aug 2026 18:40:59 +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=1786732861; cv=none; b=dWbk+kGUbj9kqqwNx9tPgKEU52sryFQK8d4o3EzXkO1l5MiGpv5l1kNlmlXaujUJSOnHKPU1ZsvwWZ7kuenADiMdxCqf9yKhH+vVmwM32KZWQ0ERlL+lceIOHVMUdJxkkLJ4exrhm++pM/0D+21DFcJevLFv+TejgV4mU3WlPoc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786732861; c=relaxed/simple; bh=Okm0dVpE3EAeyTC3g1fwL9CY5xQUka88cSGNclNk6vY=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=EMQievE7pd6MvW0igTEPvzkNc1r4qZXmAUK2cuS2Q0KLGZaN26k7SgctRSkS3I/hhcCmz0+62NHd1ZhyMUDpYzJE4CM+xs5Mp5r4CslOCX9KiSSWWA8/Ct18sg7JrCXZanJTe9B8PSxQxPIVsm7rXbXesx0zRenvkySqTOIA7SY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=MKV6Xn1V; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="MKV6Xn1V" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97ED11F000E9; Fri, 14 Aug 2026 18:40:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786732859; bh=SjynFagSsl8rrsVnx8pJ8OUq9MeSaNdTy+JC8pLJaXI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=MKV6Xn1VKPEAbBc8YKVm/3C6/b462nCDy++aVXbZ80VyB26Y6xSAZhrWBCnCCWNIG q9V7cdRdJ9cMeOTWQFp8Hg4GwqXE3ORggzTwsLohnOEeBWMa1/lnkHnNJGs+Vup2bi aMtCXQBk5NXYgduwmdC/9d02D/Q4MS8O7DDDdHnY= Date: Fri, 14 Aug 2026 11:40:59 -0700 From: Andrew Morton To: Longlong Xia Cc: Muchun Song , Oscar Salvador , David Hildenbrand , Jinjiang Tu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Longlong Xia Subject: Re: [PATCH 1/1] mm/hugetlb: keep max_huge_pages when dissolving surplus folios Message-Id: <20260814114059.c9fd2ef48f4f1b71a8b437f3@linux-foundation.org> In-Reply-To: <20260814083027.1419487-1-xialonglong2025@163.com> References: <20260814083027.1419487-1-xialonglong2025@163.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 14 Aug 2026 16:30:27 +0800 Longlong Xia wrote: > From: Longlong Xia > > dissolve_free_hugetlb_folio() can remove a free folio as surplus when > its node has surplus pages. In that case remove_hugetlb_folio() > decrements both nr_huge_pages and surplus_huge_pages, leaving the > persistent pool size unchanged. > > Updating max_huge_pages as if a persistent folio had been removed can > therefore corrupt the persistent pool target and underflow it when > max_huge_pages is zero. Keep max_huge_pages unchanged for surplus > folios, including the vmemmap restoration rollback path. Thanks. > Fixes: cb402bbdabca ("mm/hugetlb: fix surplus pages in dissolve_free_huge_page()") That's a year old, so I'm assuming there's no urgency here. I'll save the fix for later and shall await maintainer input. While at it, please suggest whether we should backport this. AI review might have found a couple of bugs in the surrounding code. If true, they look rather nasty. https://sashiko.dev/#/patchset/20260814083027.1419487-1-xialonglong2025@163.com