From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6B3BB3988E5 for ; Thu, 30 Apr 2026 07:08:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777532935; cv=none; b=lEkoT6KRn35CzBf951Jdp3sYL93HVptA2QxYeSvHVAIzq/LlUnHD5qZwCgb2FZAa4SvbEWMV6+e7BL2Ebv2/vFSJ6TtJ2UZ5wxyT62yQx6SdD2VksYCylLPMyERtofTQ8OJM6erkM1w0SmyJeIGEKJTveX4NG/zZwdsrTU9omBU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777532935; c=relaxed/simple; bh=1zhQqzqRY8FCUWn8EgF0a8ov8cOGQlh49o+pV6l4kVs=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=uK7R0wy1yPg5qbp/MlNGWgr9+4Gn6idjiuYHo2lucjSZlF5+/XzM1PAzyTnnnw1X7MLdPyuBTlnA7eMUsnqL6EkJyHmwCdN1Fx50nE9tPLbnElvGONz2hZc/T9piq4pwxyFiBH1cP9JKjk+mw/1m7nan3pATO7KfdNibrzwKU4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.42.62]) by gateway (Coremail) with SMTP id _____8DxEvACAPNpoWkFAA--.18280S3; Thu, 30 Apr 2026 15:08:50 +0800 (CST) Received: from [10.20.42.62] (unknown [10.20.42.62]) by front1 (Coremail) with SMTP id qMiowJDxzsLy__JpuPJ3AA--.31891S3; Thu, 30 Apr 2026 15:08:34 +0800 (CST) Subject: Re: [PATCH] mm/huge_memory: skip huge_zero_pmd in zap_huge_pmd_folio() To: Lance Yang Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260430070217.39679-1-lance.yang@linux.dev> From: Bibo Mao Message-ID: <6cdeb3e7-c399-4ead-e809-44e3d4d84bc7@loongson.cn> Date: Thu, 30 Apr 2026 15:05:41 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260430070217.39679-1-lance.yang@linux.dev> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:qMiowJDxzsLy__JpuPJ3AA--.31891S3 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxAF1rCr1UXryUJFy8Xw4UJrc_yoW5Cr45pF yUGFn0kr48tr9rJw1Ivw4Uta4FywnavFy5X343Kr4rZFn0yry2grsrGr4jkry0gr4rGF4S vF42vasavF9xt3gCm3ZEXasCq-sJn29KB7ZKAUJUUUUk529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUPab4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUtVW8ZwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU tVWrXwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI4 8JMxk0xIA0c2IEe2xFo4CEbIxvr21lc7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vI r41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_GFv_Wrylx2IqxVAqx4xG67 AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIY rxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_JFI_Gr1lIxAIcVC0I7IYx2IY6xkF7I0E14 v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWx JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUstxhDU UUU On 2026/4/30 下午3:02, Lance Yang wrote: > > On Thu, Apr 30, 2026 at 02:34:20PM +0800, Bibo Mao wrote: >> >> >> 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@google.com/ >>> >>>> Signed-off-by: Bibo Mao >>>> --- >>>> 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? >>> >>> [2] https://lore.kernel.org/linux-mm/ea1453a6-14c9-4334-ac7e-2758586393b2@kernel.org/ >> yes, I think it will solve this problem. >> >> Only that I think that there should be tlb flush operation after >> pmdp_huge_get_and_clear_full() even with huge_zero_pmd page, so >> tlb_remove_page_size() should be called. Is that right? > > Calling tlb_remove_page_size() is not necessary there :) > > zap_huge_pmd() already marks the PMD range for TLB invalidation right > after clearing the entry: > > orig_pmd = pmdp_huge_get_and_clear_full(...); > tlb_remove_pmd_tlb_entry(tlb, pmd, addr); Yes, it is. I forget the tlb_flush_pmd_range() calling in tlb_remove_pmd_tlb_entry(). So the fix solves this problem. And thanks for your explanation. Regards Bibo Mao > > The later tlb_remove_page_size() is guarded by "is_present && folio", > and is for the normal folio case after normal_or_softleaf_folio_pmd() > return one :) > > Please correct me if I missed something :D > > Cheers, Lance >