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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 02839CA9EC7 for ; Sat, 2 Nov 2019 07:37:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9E6962085B for ; Sat, 2 Nov 2019 07:37:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E6962085B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F8146B0005; Sat, 2 Nov 2019 03:37:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A8A66B0006; Sat, 2 Nov 2019 03:37:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F00306B0007; Sat, 2 Nov 2019 03:37:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id CA39F6B0005 for ; Sat, 2 Nov 2019 03:37:03 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 738834995E6 for ; Sat, 2 Nov 2019 07:37:03 +0000 (UTC) X-FDA: 76110531126.18.pest04_2052471d12d4b X-HE-Tag: pest04_2052471d12d4b X-Filterd-Recvd-Size: 6250 Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Sat, 2 Nov 2019 07:37:01 +0000 (UTC) Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id DD5BAD233EAD0F27D522; Sat, 2 Nov 2019 15:36:57 +0800 (CST) Received: from [127.0.0.1] (10.133.219.218) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.439.0; Sat, 2 Nov 2019 15:36:55 +0800 Message-ID: <5DBD3217.4070403@huawei.com> Date: Sat, 2 Nov 2019 15:36:55 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michal Hocko CC: , , , Subject: Re: [PATCH v3] mm: fix trying to reclaim unevictable lru page when calling madvise_pageout References: <1572616245-18946-1-git-send-email-zhongjiang@huawei.com> <20191101183220.GC29196@dhcp22.suse.cz> In-Reply-To: <20191101183220.GC29196@dhcp22.suse.cz> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.133.219.218] X-CFilter-Loop: Reflected 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: On 2019/11/2 2:32, Michal Hocko wrote: > On Fri 01-11-19 21:50:45, zhong jiang wrote: >> Recently, I hit the following issue when running in the upstream. >> >> kernel BUG at mm/vmscan.c:1521! >> invalid opcode: 0000 [#1] SMP KASAN PTI >> CPU: 0 PID: 23385 Comm: syz-executor.6 Not tainted 5.4.0-rc4+ #1 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 >> RIP: 0010:shrink_page_list+0x12b6/0x3530 mm/vmscan.c:1521 >> Code: de f5 ff ff e8 ab 79 eb ff 4c 89 f7 e8 43 33 0d 00 e9 cc f5 ff ff e8 99 79 eb ff 48 c7 c6 a0 34 2b a0 4c 89 f7 e8 1a 4d 05 00 <0f> 0b e8 83 79 eb ff 48 89 d8 48 c1 e8 03 42 80 3c 38 00 0f 85 74 >> RSP: 0018:ffff88819a3df5a0 EFLAGS: 00010286 >> RAX: 0000000000040000 RBX: ffffea00061c3980 RCX: ffffffff814fba36 >> RDX: 00000000000056f7 RSI: ffffc9000c02c000 RDI: ffff8881f70268cc >> RBP: ffff88819a3df898 R08: ffffed103ee05de0 R09: ffffed103ee05de0 >> R10: 0000000000000001 R11: ffffed103ee05ddf R12: ffff88819a3df6f0 >> R13: ffff88819a3df6f0 R14: ffffea00061c3980 R15: dffffc0000000000 >> FS: 00007f21b9d8e700(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000001b2d621000 CR3: 00000001c8c46004 CR4: 00000000007606f0 >> DR0: 0000000020000140 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 >> PKRU: 55555554 >> Call Trace: >> reclaim_pages+0x499/0x800 mm/vmscan.c:2188 >> madvise_cold_or_pageout_pte_range+0x58a/0x710 mm/madvise.c:453 >> walk_pmd_range mm/pagewalk.c:53 [inline] >> walk_pud_range mm/pagewalk.c:112 [inline] >> walk_p4d_range mm/pagewalk.c:139 [inline] >> walk_pgd_range mm/pagewalk.c:166 [inline] >> __walk_page_range+0x45a/0xc20 mm/pagewalk.c:261 >> walk_page_range+0x179/0x310 mm/pagewalk.c:349 >> madvise_pageout_page_range mm/madvise.c:506 [inline] >> madvise_pageout+0x1f0/0x330 mm/madvise.c:542 >> madvise_vma mm/madvise.c:931 [inline] >> __do_sys_madvise+0x7d2/0x1600 mm/madvise.c:1113 >> do_syscall_64+0x9f/0x4c0 arch/x86/entry/common.c:290 >> entry_SYSCALL_64_after_hwframe+0x49/0xbe >> >> madvise_pageout access the specified range of the vma and isolate >> them, then run shrink_page_list to reclaim its memory. But It also >> isolate the unevictable page to reclaim. Hence, we can catch the >> cases in shrink_page_list. >> >> The root cause is that we scan the page tables instead of specific >> LRU list. and so we need to filter out the unevictable lru pages >> from our end. >> >> Fixes: 1a4e58cce84e ("mm: introduce MADV_PAGEOUT") >> Cc: stable@vger.kernel.org >> Suggested-by: Johannes Weiner >> Signed-off-by: zhong jiang > Acked-by: Michal Hocko > > But I would really appreciate to add a comment for the BUG_ON and > explain why do we care about PageUnevictable so much when there is an > explicit page_evictable check in the reclaim path. In other words a > short summary of what Johannes explained in > http://lkml.kernel.org/r/20191030193307.GA48128@cmpxchg.org. Maybe in a > separate patch. Care to send one or should I send it? Hi, Michal Actually, I am not very clear about the words Johannes had said. How the race to tirgger, it will result in an PgeMlocked page can be visible in shrink_page_list. Could you elaborate the race in detail further ? Thanks, zhong jiang >> --- >> v2 -> v3: >> Modified the mail address to hannes@cmpxchg.org >> >> v1 -> v2: >> Remove BUG_ON is not an good solutions. Becuase it indeed can >> see !page_evictable() in shrink_page_list due to some race. >> >> mm/madvise.c | 16 ++++++++++++---- >> 1 file changed, 12 insertions(+), 4 deletions(-) >> >> diff --git a/mm/madvise.c b/mm/madvise.c >> index 99dd06f..63e1308 100644 >> --- a/mm/madvise.c >> +++ b/mm/madvise.c >> @@ -363,8 +363,12 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, >> ClearPageReferenced(page); >> test_and_clear_page_young(page); >> if (pageout) { >> - if (!isolate_lru_page(page)) >> - list_add(&page->lru, &page_list); >> + if (!isolate_lru_page(page)) { >> + if (PageUnevictable(page)) >> + putback_lru_page(page); >> + else >> + list_add(&page->lru, &page_list); >> + } >> } else >> deactivate_page(page); >> huge_unlock: >> @@ -441,8 +445,12 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, >> ClearPageReferenced(page); >> test_and_clear_page_young(page); >> if (pageout) { >> - if (!isolate_lru_page(page)) >> - list_add(&page->lru, &page_list); >> + if (!isolate_lru_page(page)) { >> + if (PageUnevictable(page)) >> + putback_lru_page(page); >> + else >> + list_add(&page->lru, &page_list); >> + } >> } else >> deactivate_page(page); >> } >> -- >> 1.7.12.4