From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 373D6C433ED for ; Fri, 23 Apr 2021 02:16:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4A3836141C for ; Fri, 23 Apr 2021 02:16:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A3836141C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=e16-tech.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B6BC16B00BB; Thu, 22 Apr 2021 22:16:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1B596B00BC; Thu, 22 Apr 2021 22:16:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E3306B00BD; Thu, 22 Apr 2021 22:16:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id 7CC836B00BB for ; Thu, 22 Apr 2021 22:16:57 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 418138248047 for ; Fri, 23 Apr 2021 02:16:57 +0000 (UTC) X-FDA: 78062018874.23.546B0FD Received: from out20-63.mail.aliyun.com (out20-63.mail.aliyun.com [115.124.20.63]) by imf30.hostedemail.com (Postfix) with ESMTP id 53BFBE00011D for ; Fri, 23 Apr 2021 02:16:38 +0000 (UTC) X-Alimail-AntiSpam:AC=CONTINUE;BC=0.04899119|-1;CH=green;DM=|CONTINUE|false|;DS=CONTINUE|ham_regular_dialog|0.0189096-6.35192e-05-0.981027;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047211;MF=wangyugui@e16-tech.com;NM=1;PH=DS;RN=3;RT=3;SR=0;TI=SMTPD_---.K2az1rd_1619144210; Received: from 192.168.2.112(mailfrom:wangyugui@e16-tech.com fp:SMTPD_---.K2az1rd_1619144210) by smtp.aliyun-inc.com(10.147.42.135); Fri, 23 Apr 2021 10:16:51 +0800 Date: Fri, 23 Apr 2021 10:16:55 +0800 From: Wang Yugui To: Yang Shi Subject: Re: kernel BUG at mm/huge_memory.c:2736(linux 5.10.29) Cc: "Kirill A. Shutemov" , Linux MM In-Reply-To: References: <20210417163337.AA58.409509F4@e16-tech.com> Message-Id: <20210423101654.1242.409509F4@e16-tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.75.03 [en] X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 53BFBE00011D X-Stat-Signature: qsjbs1i4mq7odih4ypx9g4mtzugqg8yb Received-SPF: none (e16-tech.com>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=out20-63.mail.aliyun.com; client-ip=115.124.20.63 X-HE-DKIM-Result: none/none X-HE-Tag: 1619144198-497774 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, > On Sat, Apr 17, 2021 at 1:33 AM Wang Yugui wrote: > > > > Hi, > > > > > On Mon, Apr 12, 2021 at 3:07 AM Wang Yugui wrote: > > > > > > > > Hi, > > > > > > > > kernel BUG at mm/huge_memory.c:2736(linux 5.10.29) is triggered > > > > by some files write test. > > > > > > > > mm/huge_memory.c: > > > > if (IS_ENABLED(CONFIG_DEBUG_VM) && mapcount) { > > > > pr_alert("total_mapcount: %u, page_count(): %u\n", > > > > mapcount, count); > > > > if (PageTail(page)) > > > > dump_page(head, NULL); > > > > dump_page(page, "total_mapcount(head) > 0"); > > > > L2736: BUG(); > > > > } > > > > > > We just can tell the mapcount of the page is not zero from the current > > > log, it might mean the unmap_page() call is failed. It seems you have > > > CONFIG_DEBUG_VM enabled, could you please paste more log? There is > > > "VM_BUG_ON_PAGE(!unmap_success, page)" in unmap_page(). It should be > > > able to tell us if unmap_page() is failed or not, or something else > > > happened. > > > > This is the full dmesg output > > > > [63080.331513] huge_memory: total_mapcount: 511, page_count(): 512 > > [63080.332167] page:00000000d2e1a982 refcount:512 mapcount:0 mapping:0000000000000000 index:0x7fe260582 pfn:0x676a00 > > [63080.332167] head:00000000d2e1a982 order:9 compound_mapcount:0 compound_pincount:0 > > [63080.332167] anon flags: 0x17ffffc009001d(locked|uptodate|dirty|lru|head|swapbacked) > > [63080.332167] raw: 0017ffffc009001d ffffc93cda0d0008 ffffc93cd9ab0008 ffff8f21be9f0cb9 > > [63080.332167] raw: 00000007fe260582 0000000000000000 00000200ffffffff ffff8f1021810000 > > [63080.332167] page->mem_cgroup:ffff8f1021810000 > > [63080.332167] page:00000000bc78ac24 refcount:512 mapcount:1 mapping:0000000000000000 index:0x7fe260584 pfn:0x676a02 > > [63080.332167] head:00000000d2e1a982 order:9 compound_mapcount:0 compound_pincount:0 > > [63080.332167] anon flags: 0x17ffffc009001d(locked|uptodate|dirty|lru|head|swapbacked) > > [63080.332167] raw: 0017ffffc0000000 ffffc93cd9da8001 dead000000000000 ffffc93d428d0098 > > [63080.332167] raw: ffffa002cd183bf0 0000000000000000 0000000000000000 0000000000000000 > > [63080.332167] head: 0017ffffc009001d ffffc93cda0d0008 ffffc93cd9ab0008 ffff8f21be9f0cb9 > > [63080.332167] head: 00000007fe260582 0000000000000000 00000200ffffffff ffff8f1021810000 > > [63080.332167] page dumped because: total_mapcount(head) > 0 > > Added Kirill in this loop too, he may have some insights. > > Thanks a lot for pasting the full log. It seems the BUG_ON in > unmap_page() and VM_BUG_ON_PAGE(compound_mapcount(head), head) were > not triggered. But the dumped page shows its total_mapcount is 511. It > means 511 subpages of the huge page are PTE mapped. It seems all tail > pages are PTE mapped. It may be because unmap_page() is failed or they > are mapped again after unmap_page(). > > But the VM_BUG_ON_PAGE just checks compound_mapcount, and it seems > page_mapcount() call in unmap_page() also just checks > compound_mapcount and the mapcount of the head page. If the mapcount > of the head page is 0 and compound_mapcount is also 0, try_to_unmap() > considers unmap is successful. > > So we can't tell which case it is although I don't think of how > unmap_page() could fail for this case. I think we should check the > total mapcount in try_to_unmap() instead. > > Can you please try the below debug patch (untested) to help narrow > down the problem? > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index ae907a9c2050..c10e89be1c99 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2726,7 +2726,7 @@ int split_huge_page_to_list(struct page *page, > struct list_head *list) > } > > unmap_page(head); > - VM_BUG_ON_PAGE(compound_mapcount(head), head); > + VM_BUG_ON_PAGE(total_mapcount(head), head); > > /* block interrupt reentry in xa_lock and spinlock */ > local_irq_disable(); > diff --git a/mm/rmap.c b/mm/rmap.c > index b0fc27e77d6d..537dfc557744 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1777,7 +1777,7 @@ bool try_to_unmap(struct page *page, enum ttu_flags flags) > else > rmap_walk(page, &rwc); > > - return !page_mapcount(page) ? true : false; > + return !total_mapcount(page) ? true : false; > } > > /** > > With this patch, the problem yet not happen after 4 tests(5.10.x). By the way, the problem does not happen in 5.4.x.(>about 120 tests) does this match the code version? Best Regards Wang Yugui (wangyugui@e16-tech.com) 2021/04/23