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 A3A35CA9EC0 for ; Tue, 29 Oct 2019 02:52:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8D9920663 for ; Tue, 29 Oct 2019 02:52:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8D9920663 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 5656D6B0005; Mon, 28 Oct 2019 22:52:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 515E96B0006; Mon, 28 Oct 2019 22:52:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 406076B0007; Mon, 28 Oct 2019 22:52:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 1CA706B0005 for ; Mon, 28 Oct 2019 22:52:43 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id A9E40641D for ; Tue, 29 Oct 2019 02:52:42 +0000 (UTC) X-FDA: 76095299364.10.cow01_518b6a7b80308 X-HE-Tag: cow01_518b6a7b80308 X-Filterd-Recvd-Size: 6280 Received: from huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Oct 2019 02:52:40 +0000 (UTC) Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 8E9A89620BA376D7A577; Tue, 29 Oct 2019 10:52:31 +0800 (CST) Received: from [127.0.0.1] (10.133.219.218) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.439.0; Tue, 29 Oct 2019 10:52:28 +0800 Message-ID: <5DB7A96B.8090104@huawei.com> Date: Tue, 29 Oct 2019 10:52:27 +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: Yang Shi CC: Andrew Morton , , "John Hubbard" , "Kirill A. Shutemov" , , Linux MM Subject: Re: [PATCH] mm: put the page into the correct list when shrink_page_list fails to reclaim. References: <1572269624-60283-1-git-send-email-zhongjiang@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" 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/10/29 2:47, Yang Shi wrote: > On Mon, Oct 28, 2019 at 6:37 AM zhong jiang wrote: >> Recently, I notice an race case between mlock syscall and shrink_page_list. >> >> one cpu run mlock syscall to make an range of the vma locked in memory. And >> The specified pages will escaped from evictable list from unevictable. >> Meanwhile, another cpu scan and isolate the specified pages to reclaim. >> shrink_page_list hold the page lock to shrink the page and follow_page_pte >> will fails to get the page lock, hence we fails to mlock the page to make >> it Unevictabled. >> >> shrink_page_list fails to reclaim the page due to some reason. it will putback >> the page to evictable lru. But the page actually belongs to an locked range of >> the vma. it is unreasonable to do that. It is better to put the page to unevictable >> lru. > Yes, there is definitely race between mlock() and vmscan, and in the > above case it might stay in evictable LRUs one more round, but it > should be not harmful since try_to_unmap() would move the page to > unevictable list eventually. The key is how to make sure try_to_unmap alway will be called before the page is freed. It is possibility page_mapped(page) is false due to some condition. Thanks, zhong jiang >> The patch set PageMlocked when mlock fails to get the page locked. shrink_page_list >> fails to reclaim the page will putback to the correct list. if it success to reclaim >> the page, we should ClearPageMlocked in time to prevent the warning from free_pages_prepare. >> >> Signed-off-by: zhong jiang >> --- >> mm/gup.c | 28 ++++++++++++++++++---------- >> mm/vmscan.c | 9 ++++++++- >> 2 files changed, 26 insertions(+), 11 deletions(-) >> >> diff --git a/mm/gup.c b/mm/gup.c >> index c2b3e11..c26d28c 100644 >> --- a/mm/gup.c >> +++ b/mm/gup.c >> @@ -283,16 +283,24 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, >> * handle it now - vmscan will handle it later if and >> * when it attempts to reclaim the page. >> */ >> - if (page->mapping && trylock_page(page)) { >> - lru_add_drain(); /* push cached pages to LRU */ >> - /* >> - * Because we lock page here, and migration is >> - * blocked by the pte's page reference, and we >> - * know the page is still mapped, we don't even >> - * need to check for file-cache page truncation. >> - */ >> - mlock_vma_page(page); >> - unlock_page(page); >> + if (page->mapping) { >> + if (trylock_page(page)) { >> + lru_add_drain(); /* push cached pages to LRU */ >> + /* >> + * Because we lock page here, and migration is >> + * blocked by the pte's page reference, and we >> + * know the page is still mapped, we don't even >> + * need to check for file-cache page truncation. >> + */ >> + mlock_vma_page(page); >> + unlock_page(page); >> + } else { >> + /* >> + * Avoid putback the page to evictable list when >> + * the page is in the locked vma. >> + */ >> + SetPageMlocked(page); >> + } >> } >> } >> out: >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 1154b3a..f7d1301 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1488,8 +1488,15 @@ static unsigned long shrink_page_list(struct list_head *page_list, >> */ >> if (unlikely(PageTransHuge(page))) >> (*get_compound_page_dtor(page))(page); >> - else >> + else { >> + /* >> + * There is an race between mlock and shrink_page_list >> + * when mlock fails to get the PageLocked(). >> + */ >> + if (unlikely(PageMlocked(page))) >> + ClearPageMlocked(page); >> list_add(&page->lru, &free_pages); >> + } >> continue; >> >> activate_locked_split: >> -- >> 1.7.12.4 >> >> > . >