From patchwork Mon Oct 28 13:33:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: zhong jiang X-Patchwork-Id: 11215533 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C65F9112B for ; Mon, 28 Oct 2019 13:37:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9CEBD214D9 for ; Mon, 28 Oct 2019 13:37:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CEBD214D9 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 CEC0A6B0003; Mon, 28 Oct 2019 09:37:51 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id C9B386B0007; Mon, 28 Oct 2019 09:37:51 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB10F6B000A; Mon, 28 Oct 2019 09:37:51 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 9986B6B0003 for ; Mon, 28 Oct 2019 09:37:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 27CC96135 for ; Mon, 28 Oct 2019 13:37:51 +0000 (UTC) X-FDA: 76093296342.29.swim10_7e86646ec0a63 X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,zhongjiang@huawei.com,:akpm@linux-foundation.org:ira.weiny@intel.com:jhubbard@nvidia.com:kirill.shutemov@linux.intel.com:rppt@linux.ibm.com:zhongjiang@huawei.com:,RULES_HIT:30054:30070,0,RBL:45.249.212.32:@huawei.com:.lbl8.mailshell.net-62.18.2.100 64.95.201.95,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: swim10_7e86646ec0a63 X-Filterd-Recvd-Size: 4155 Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 28 Oct 2019 13:37:49 +0000 (UTC) Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 80FCE9882EE055ADF384; Mon, 28 Oct 2019 21:37:44 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.439.0; Mon, 28 Oct 2019 21:37:34 +0800 From: zhong jiang To: CC: , , , , , Subject: [PATCH] mm: put the page into the correct list when shrink_page_list fails to reclaim. Date: Mon, 28 Oct 2019 21:33:44 +0800 Message-ID: <1572269624-60283-1-git-send-email-zhongjiang@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] 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: 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. 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: