From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 5B563282F03; Wed, 6 May 2026 05:11:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778044315; cv=none; b=Lno3jasgStbGWn+AMBpPrwi+FACOvzugb81KX/yo6ApgEiwnJshfluyuA50+aJA8NKlIT1MP9HXqi6ql+wm+zX7QS553TCLDOPSnf7YnDHWr1AWoCK1C6HRfEjnCoHrsHupvIxnohaa6nfdu1NCa5Rwkk6YPaRZw+F7hYPY7J5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778044315; c=relaxed/simple; bh=YRlHKj4bTPlIKFkhJqLYD2+yDzzIt1X5PxSxX1g3tiY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JsBmjpkvla/TIJP4o+oOtovFwdDZV+YfoK1cH3GK7qqfZ8QFF9aIzNT0A1DBjNo4+MMzlDpmsrec/tF9mT+sqVQux9LxYWODBC42fitnnkyr1QGY3yNygOlNONIUvm4p0dEMpEo3/Y+4tsBNZfzD+QOhOIAsMsSpsG5PLbn09uI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=BAPrhnrO; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="BAPrhnrO" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1778044308; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=Yjv1YwoUlV3YcbGhSBZo4j1p+egaq8G4dSfMBztXKz4=; b=BAPrhnrOwoZ5HEj0xpQQ1ywHimaNhmpbndqTLCEWBAcjgSQMTmT89xZ34bVrxfEcFYTFvconNPUIj+OCXCDKWgoZMcqSNhb2iGPf9P6w3DRsJiIyUSJfKBEoL+2Ay9GgEHbyhFiQ4LSw4r6jtDnd7IMtikF//8yz/Tc1jZOWXbM= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0X2L9Eve_1778044305; Received: from 30.221.149.158(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X2L9Eve_1778044305 cluster:ay36) by smtp.aliyun-inc.com; Wed, 06 May 2026 13:11:46 +0800 Message-ID: <1a5c8084-c244-455b-b999-f110fc9e4749@linux.alibaba.com> Date: Wed, 6 May 2026 13:11:44 +0800 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special() To: "David Hildenbrand (Arm)" , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Oscar Salvador , Hugh Dickins , Lance Yang Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Bibo Mao , stable@vger.kernel.org References: <20260430-pmd_special-v1-1-dbcbcfd72c20@kernel.org> From: Baolin Wang In-Reply-To: <20260430-pmd_special-v1-1-dbcbcfd72c20@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/30/26 7:31 PM, David Hildenbrand (Arm) wrote: > On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a > "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the > VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed > by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s > when reclaim gets to call shrink_huge_zero_folio_scan(). > > It's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: > and indeed, whereas pte_special() and pte_mkspecial() are subject to a > dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial() > are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled > on any 32-bit architecture. > > While the problem was exposed through commit d80a9cb1a64a ("mm/huge_memory: > add and use normal_or_softleaf_folio_pmd()"), it was an oversight in commit > af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") > and would result in other problems: > * huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and > numamaps as file-backed THP > * folio_walk_start() returning the folio even without FW_ZEROPAGE set. > Callers seem to tolerate that, though. > > ... and triggering the VM_WARN_ON_ONE(), although never reported so far. > > To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider > whether pmd_special/pud_special is actually implemented. > > Fixes: af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") > Reported-by: Hugh Dickins > Closes: https://lore.kernel.org/r/74a75b59-2e13-3985-ee99-d5521f39df2a@google.com > Reported-by: Bibo Mao > Closes: https://lore.kernel.org/r/20260430041121.2839350-1-maobibo@loongson.cn > Debugged-by: Hugh Dickins > Reviewed-by: Lance Yang > Tested-by: Bibo Mao > Cc: stable@vger.kernel.org > Signed-off-by: David Hildenbrand (Arm) > --- LGTM. Feel free to add: Reviewed-by: Baolin Wang