From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.5]) (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 71B843AAF76 for ; Mon, 17 Aug 2026 14:04:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786975500; cv=none; b=tvSm4jzLw2pG5DqEjFkwwd06QDVoTjS5HMywUtzlVzErowWb711IbZcU6BQQloMxBrvjvt0/0vydQ6B+vkPF6myPBX2fckK+P3BpgatvSqdgWrgu41zoK6Q6/4OMRSevowxX2mXcF1bP6SGN+6xL1Sgpe5161BBrhAdTw/mgLnw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786975500; c=relaxed/simple; bh=nfx8Umo1J7+RDvFoQPNOunACSkIOYJ7SzOEg/KTkQAo=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=uWa18oGXwezAbvfKcX9Mdzst9e7yXmHmzx/IEpkGwZePH9uf0Xz624Gdh4vdth1gAdn2NECEYnWn+S1HjWEDfC5m+5VdSVQzS6ETPQpOlhRzPZ1bFecvnnIRKRdBQ8CtLNXF63hGtiAkzyl5PbJJe2L8t+WKd8mFP2lb0392cbA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=Xu7X2QLE; arc=none smtp.client-ip=220.197.31.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="Xu7X2QLE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:Date:MIME-Version:From:Subject:To: Content-Type; bh=EthaWre51vm4c4XQ+XHjPvEXxi4SWd7KGNAMp4EnZNM=; b=Xu7X2QLE3T6INq1REmKc271AiaD6H2fpUf0fJ8rhTAOLh0pfbyqzx9xhhSrQCM byF79jZBuHKCSO4vdPHwvZLehVIWRLF2FgzaHt+BUesJmaUy3M+UAioUpVAUEcJC zZSkwexp2dKGTVFjJdegOUFNvCYeKeV0Jh4fuqqUsP2iE= Received: from [198.18.0.1] (unknown []) by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id _____wBXkO+_FINqYOyyCA--.6431S2; Mon, 17 Aug 2026 22:03:44 +0800 (CST) Message-ID: Date: Mon, 17 Aug 2026 22:03:44 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Longlong Xia Subject: Re: [PATCH 1/1] mm/hugetlb: keep max_huge_pages when dissolving surplus folios To: Andrew Morton Cc: Muchun Song , Oscar Salvador , David Hildenbrand , Jinjiang Tu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Longlong Xia References: <20260814083027.1419487-1-xialonglong2025@163.com> <20260814114059.c9fd2ef48f4f1b71a8b437f3@linux-foundation.org> In-Reply-To: <20260814114059.c9fd2ef48f4f1b71a8b437f3@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wBXkO+_FINqYOyyCA--.6431S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KryrGF47Gw1rZr4rKFy7trb_yoW8CF4UpF yDGws8uFW8JFyvyr1xtFyjy3W5Ary3JrW8ta43tw43JF15C3srKryfta4Y9ayvyrn5Ja1I 9rWqg39rWFn0vaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U6UDAUUUUU= X-CM-SenderInfo: x0ldz0pqjo00rjsqjki6rwjhhfrp/xtbC+AGwqWqDFMHZOQAA38 Hi Andrew, I'd suggest backporting this. cb402bbdabca reached mainline in v6.14 and the -stable branches from v6.14.1 on (6.14.y–7.1.y), so those carry the max_huge_pages corruption; The fix is four lines on two accounting spots, low risk. 在 2026/8/15 2:40, Andrew Morton 写道: > 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 The AI findings are real but pre-existing: dissolve_free_hugetlb_folio() doesn't check hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/update_and_free_hugetlb_folio() silently bail for such folios, so it frees a still-listed folio and, on vmemmap restore failure, the add_hugetlb_folio() rollback corrupts the free list. I will send separately fix patch. Thanks， Longlong