Re: [PATCH] mm/huge_memory: skip huge_zero_pmd in zap_huge_pmd_folio()

[Lance Yang]

On 2026/4/30 12:28, Lance Yang wrote:
> On Thu, Apr 30, 2026 at 12:11:20PM +0800, Bibo Mao wrote:
> > when executing command "make check" with qemu software, there is
> > error report like this:
> > BUG: Bad rss-counter state mm:00000000972846bc type:MM_FILEPAGES val:-4096 Comm:bios-tables-tes Pid:27802
> > BUG: Bad rss-counter state mm:00000000752180c5 type:MM_FILEPAGES val:-2048 Comm:worker Pid:27815
> > BUG: Bad rss-counter state mm:000000009c2f6a61 type:MM_FILEPAGES val:-2048 Comm:qom-test Pid:27825
>
> Good catch!
>
> > The problem is that when application exits, rss counter is calculated
> > with huge_zero_pmd huge page, instead it should be skipped.
>
> Looks like the same problem[1] we discussed recently.
>
> [1] https://lore.kernel.org/linux-mm/74a75b59-2e13-3985-ee99-d5521f39df2a@xxxxxxxxxx/
>
> > Signed-off-by: Bibo Mao <maobibo@xxxxxxxxxxx>
> > ---
> > mm/huge_memory.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 970e077019b7..3cbea344d4a2 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2423,6 +2423,9 @@ static void zap_huge_pmd_folio(struct mm_struct *mm, struct vm_area_struct *vma,
> > {
> > 	const bool is_device_private = folio_is_device_private(folio);
> >
> > +	if (is_huge_zero_pmd(pmdval))
> > +		return;
> > +
>
> The huge zero PMD should not be returned by vm_normal_page_pmd() or
> vm_normal_folio_pmd() as a normal folio. If it reaches
> zap_huge_pmd_folio(), we already made the wrong normal-vs-special
> decision ...
>
> So I don't think we should special-case it in zap_huge_pmd_folio(). That
> only avoids this RSS decrement :)
>
> Could you please check whether the fix[2] also fixes your QEMU test?

In addition, like x86-32, 64-bit LoongArch selects ARCH_HAS_PTE_SPECIAL,
but not ARCH_SUPPORTS_HUGE_PFNMAP. So CONFIG_ARCH_SUPPORTS_PMD_PFNMAP
is not enabled, and pmd_special() falls back to the generic stub that
always returns false.

So I guess the fix should do the trick :)

> [2] https://lore.kernel.org/linux-mm/ea1453a6-14c9-4334-ac7e-2758586393b2@xxxxxxxxxx/
>
> Thanks, Lance