Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp12791ybg; Wed, 18 Mar 2020 16:21:51 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtd/or0MXMJSB2FfQ0T6VqF+thWGJg9eYi9cV5OxJSwiEzx9CI/mYrmpbCBfwutvxlL/WIb X-Received: by 2002:aca:b7c1:: with SMTP id h184mr318331oif.77.1584573711800; Wed, 18 Mar 2020 16:21:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584573711; cv=none; d=google.com; s=arc-20160816; b=S6TDW/7JAr/DbVinB4iqNOWB1CR0lmYN/zy6gYZ9cSRoWBfSNjFkac7uR4a+2fBYnY OgYOJcZrS2KJg2sqI0P1Ggr68yssE0ns8PiIokCBuLU8xGbaWeUNoe+5xcGLT801zAzh IaSNiYYsRC1FafAF6N7xIjAGPsx82O/yU5xf7XxkOljV+plC6uF2X5tiVPktAg0jaJVp ov33UTlLw/W37DE5B1Q8JNkuGDH0ZqCPQQdk3ggPOh26MKlEtNahli47fGq8wo8PTHJd aTtuJgtBz76HRyxQiXlkqneX8cldXt2mZoJg7yroyBKK898j4ZjHnnKnJ9LHHW/qP25h Qg9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=FbkQD3EWsCuhuCph0yS1zoaeTRliI/eNAIBlyHKxKCg=; b=pjQ3ko0CDR/1Mukq/uYRPO4RcvyhE/07z/H9RFbgInBQ5EoWYrWrPybasy7oLryfRD AkY0UOm1DqyE/YC4Y0mqiY9N1aGVH/woDSB458mFEDpR9jmljaiWwYwyTpF9k5ZAlX22 mdXNxlpvf1ETM71cJxTCdZTvoltDwe1IUu5qD0JL1n231fSpz+qxUJkNHfxT1K9QjEsn p8jBcwWlXtVqBLg/v/iKYnyXAlbVa+bVwqqPRVGamua2PcLBXMtPLgm9/bCU17UCko4I UPez8tN2gDWOlq1OOdA/ZDqLJ/tjyStcT2afm5HrmFNqVEcaEyVrDxiA+QIcFyw34gGt C/oQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m20si257699otk.238.2020.03.18.16.21.38; Wed, 18 Mar 2020 16:21:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727350AbgCRXTx (ORCPT + 99 others); Wed, 18 Mar 2020 19:19:53 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:51619 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726619AbgCRXTx (ORCPT ); Wed, 18 Mar 2020 19:19:53 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04452;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0Tt-L-mT_1584573582; Received: from localhost(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0Tt-L-mT_1584573582) by smtp.aliyun-inc.com(127.0.0.1); Thu, 19 Mar 2020 07:19:49 +0800 From: Yang Shi To: kirill.shutemov@linux.intel.com, hughd@google.com, aarcange@redhat.com, akpm@linux-foundation.org Cc: yang.shi@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm: khugepaged: fix potential page state corruption Date: Thu, 19 Mar 2020 07:19:42 +0800 Message-Id: <1584573582-116702-1-git-send-email-yang.shi@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When khugepaged collapses anonymous pages, the base pages would be freed via pagevec or free_page_and_swap_cache(). But, the anonymous page may be added back to LRU, then it might result in the below race: CPU A CPU B khugepaged: unlock page putback_lru_page add to lru page reclaim: isolate this page try_to_unmap page_remove_rmap <-- corrupt _mapcount It looks nothing would prevent the pages from isolating by reclaimer. The other problem is the page's active or unevictable flag might be still set when freeing the page via free_page_and_swap_cache(). The putback_lru_page() would not clear those two flags if the pages are released via pagevec, it sounds nothing prevents from isolating active or unevictable pages. However I didn't really run into these problems, just in theory by visual inspection. And, it also seems unnecessary to have the pages add back to LRU again since they are about to be freed when reaching this point. So, clearing active and unevictable flags, unlocking and dropping refcount from isolate instead of calling putback_lru_page() as what page cache collapse does. Cc: Kirill A. Shutemov Cc: Hugh Dickins Cc: Andrea Arcangeli Signed-off-by: Yang Shi --- mm/khugepaged.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index b679908..f42fa4e 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -673,7 +673,6 @@ static void __collapse_huge_page_copy(pte_t *pte, struct page *page, src_page = pte_page(pteval); copy_user_highpage(page, src_page, address, vma); VM_BUG_ON_PAGE(page_mapcount(src_page) != 1, src_page); - release_pte_page(src_page); /* * ptl mostly unnecessary, but preempt has to * be disabled to update the per-cpu stats @@ -687,6 +686,15 @@ static void __collapse_huge_page_copy(pte_t *pte, struct page *page, pte_clear(vma->vm_mm, address, _pte); page_remove_rmap(src_page, false); spin_unlock(ptl); + + dec_node_page_state(src_page, + NR_ISOLATED_ANON + page_is_file_cache(src_page)); + ClearPageActive(src_page); + ClearPageUnevictable(src_page); + unlock_page(src_page); + /* Drop refcount from isolate */ + put_page(src_page); + free_page_and_swap_cache(src_page); } } -- 1.8.3.1