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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 DCF00CA9EC0 for ; Mon, 28 Oct 2019 16:16:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9130C20873 for ; Mon, 28 Oct 2019 16:16:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G21SbDU/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9130C20873 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 436086B0008; Mon, 28 Oct 2019 12:16:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3ECE66B000A; Mon, 28 Oct 2019 12:16:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FD436B000C; Mon, 28 Oct 2019 12:16:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id 0C7236B0008 for ; Mon, 28 Oct 2019 12:16:07 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 99CBE4DA6 for ; Mon, 28 Oct 2019 16:16:06 +0000 (UTC) X-FDA: 76093695132.02.side89_3544b74777612 X-HE-Tag: side89_3544b74777612 X-Filterd-Recvd-Size: 8256 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Oct 2019 16:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572279365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2EipV8qWiOvasXNIaKT5Gj3MUIno7RIL+ZvJKhdShcA=; b=G21SbDU/EfZcH1JRyF9U3GotwVu4xj9B1Sl0C729sFEb/vuSn0JquaxylbVVKzpe9WtD4e Ch79Um3C0NYiKC4n63LyoFZelzowhmNsyf2+hcrvFO70fQZwyY6P4p0PvhYc0OrPvQgpn/ n70BGV43+JGArcoH+pMQH7Y+LhrQ/m0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-WxCnXChUPd2r5gPyN-uNiQ-1; Mon, 28 Oct 2019 12:16:01 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5A41D81A334; Mon, 28 Oct 2019 16:16:00 +0000 (UTC) Received: from [10.36.117.63] (ovpn-117-63.ams2.redhat.com [10.36.117.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 605FD100032E; Mon, 28 Oct 2019 16:15:58 +0000 (UTC) Subject: Re: [PATCH] mm: fix unevictable page reclaim when calling madvise_pageout From: David Hildenbrand To: zhong jiang Cc: akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, ktkhai@virtuozzo.com, linux-mm@kvack.org, Minchan Kim References: <1572275317-63910-1-git-send-email-zhongjiang@huawei.com> <3ac2e87d-2899-ab17-8b0b-8aa6a5035d4a@redhat.com> <5DB70D17.9040108@huawei.com> <991592a5-e8a3-f392-f330-e2e1b582fb6a@redhat.com> Organization: Red Hat GmbH Message-ID: <4697f081-933b-6620-8c94-4b8c6a6f661d@redhat.com> Date: Mon, 28 Oct 2019 17:15:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <991592a5-e8a3-f392-f330-e2e1b582fb6a@redhat.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: WxCnXChUPd2r5gPyN-uNiQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 28.10.19 17:07, David Hildenbrand wrote: > On 28.10.19 16:45, zhong jiang wrote: >> On 2019/10/28 23:27, David Hildenbrand wrote: >>> On 28.10.19 16:08, 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-1ub= untu1 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 f= f 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:0000000000= 000000 >>>> 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 the memory. But It also >>>> isolate the unevictable page to reclaim. Hence, we can catch the >>>> cases in shrink_page_list. >>>> >>>> We can fix it by preventing unevictable page from isolating. >>>> Another way to fix the issue by removing the condition of >>>> BUG_ON(PageUnevictable(page)) in shrink_page_list. I think it >>>> is better to use the latter. Because We has taken the unevictable >>>> page and skip it into account in shrink_page_list. >>> I really don't understand the last sentence. Looks like >>> something got messed up :) >> I mean that we will check the page_evictable(page) in shrink_page_list, >> if it is unevictable page, we will put the page back to correct lru. >> >> Based on the condition, I make the choice. It seems to more simpler.:-) >> >> Thanks, >> zhong jiang >>> >>>> Signed-off-by: zhong jiang >>>> --- >>>> mm/vmscan.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>>> index f7d1301..1c6e959 100644 >>>> --- a/mm/vmscan.c >>>> +++ b/mm/vmscan.c >>>> @@ -1524,7 +1524,7 @@ static unsigned long shrink_page_list(struct lis= t_head *page_list, >>>> =09=09unlock_page(page); >>>> keep: >>>> =09=09list_add(&page->lru, &ret_pages); >>>> -=09=09VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page); >>>> +=09=09VM_BUG_ON_PAGE(PageLRU(page), page); >>> So, this comes from >>> >>> commit b291f000393f5a0b679012b39d79fbc85c018233 >>> Author: Nick Piggin >>> Date: Sat Oct 18 20:26:44 2008 -0700 >>> >>> mlock: mlocked pages are unevictable >>> =20 >>> Make sure that mlocked pages also live on the unevictable LRU, so= kswapd >>> will not scan them over and over again. >>> >>> >>> That patch is fairly old. How come we can suddenly trigger this? >>> Which commit is responsible for that? Was it always broken? >>> >>> I can see that >>> >>> commit ad6b67041a45497261617d7a28b15159b202cb5a >>> Author: Minchan Kim >>> Date: Wed May 3 14:54:13 2017 -0700 >>> >>> mm: remove SWAP_MLOCK in ttu >>> >>> Performed some changes in that area. But also some time ago. >> I think the following patch introduce the issue. >> >> commit 1a4e58cce84ee88129d5d49c064bd2852b481357 >> Author: Minchan Kim >> Date: Wed Sep 25 16:49:15 2019 -0700 >> >> mm: introduce MADV_PAGEOUT >> >> When a process expects no accesses to a certain memory range for a= long >> >=20 > CCing Minchan Kim then. >=20 > If this is indeed the introducing patch, you probably reference that > patch in your cover mail somehow. (Fixes: does not apply until upstream) >=20 > I am absolutely no expert on vmscan.c, so I'm afraid I can't really > comment on the details. >=20 Oh, and just wondering, is this the same BUG as in https://lkml.org/lkml/2019/8/2/1506 Where a fix has been proposed? The fix does not seem to be in=20 next/master yet. (I just realized that it is already upstream so "Fixes: =091a4e58cce84e=20 ("mm: introduce MADV_PAGEOUT")) applies. --=20 Thanks, David / dhildenb