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=-6.8 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 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 94E93CA9ECF for ; Fri, 1 Nov 2019 21:49:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B810217D9 for ; Fri, 1 Nov 2019 21:49:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fb.com header.i=@fb.com header.b="AEc0Rb5J"; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.i=@fb.onmicrosoft.com header.b="Xri4t8FA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B810217D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=fb.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD58C6B0005; Fri, 1 Nov 2019 17:49:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5FB36B0006; Fri, 1 Nov 2019 17:49:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D6CA6B0007; Fri, 1 Nov 2019 17:49:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id 6F8926B0005 for ; Fri, 1 Nov 2019 17:49:10 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id EF9DD180AD820 for ; Fri, 1 Nov 2019 21:49:09 +0000 (UTC) X-FDA: 76109049618.15.range22_8a1ecf6940b1c X-HE-Tag: range22_8a1ecf6940b1c X-Filterd-Recvd-Size: 21527 Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 1 Nov 2019 21:49:09 +0000 (UTC) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.42/8.16.0.42) with SMTP id xA1LlgBA003507; Fri, 1 Nov 2019 14:48:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=n4Lc4hplX5RdJVLekZnssa5FS5JYpAMp9U0MgSWY2R4=; b=AEc0Rb5JuYCyRSi81UFQu6TWwWA5g4EnC/s5RDRq4ydA4URvFnK5NPXbOZTsKE0f3Lqe QKBuX/8NIArV8uJOg83uaHm7G/OixcYFzkuGCvSQNRr1M2rqUUxJfM1Zwr4nWw5PltiX snNRH+pd5HgX7EgRUkXkFnAX3cOGc+NInGg= Received: from mail.thefacebook.com (mailout.thefacebook.com [199.201.64.23]) by m0001303.ppops.net with ESMTP id 2w0ttk0n47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Nov 2019 14:48:57 -0700 Received: from prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) by prn-hub06.TheFacebook.com (2620:10d:c081:35::130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 1 Nov 2019 14:48:56 -0700 Received: from prn-hub04.TheFacebook.com (2620:10d:c081:35::128) by prn-mbx01.TheFacebook.com (2620:10d:c081:6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 1 Nov 2019 14:48:56 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Fri, 1 Nov 2019 14:48:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y/I5zjreYACn+Fh1JdTg0BRQ3MvDkMWyT1itN40aqjwYTNBzZzol7Kvv5G7kzxtCoFKlSNhRMsHoJLuYDn9rl7STa2ZQp+vhCpc2OQFn8pZCf51QgJfQMWSmBaPO7NKssoGOlQzypb/X32MDdX0nk3IJSjnLU6YxWalObaKbRvSHrEg5KJLRwT9hekouNQTFMgdLfulNdGM1EmcYnDqsv+8ROjK6kdVF4j9hN0qoh7GEVONZBO/kWECfTFwPuYbYuTnD05/QSad9I0rrCjg3oxHqoH8Yo6MzYKqUj5QnXPbAd+NPmy88trWWd93+3bOvNqVRFgjn5UfVVl7y9otKSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4Lc4hplX5RdJVLekZnssa5FS5JYpAMp9U0MgSWY2R4=; b=VohYT1XYcvfDmKWhMKupl5s9T+5mciPQVFsDCA/6wyuaCNhb5KGwSYEEDEfK+U1sTKV2vWExQIjsAugWXlWouspp4T0Z+WdTSOTsEMPG4C46Kq8Nc4xU5jxpEZ3szXQZz5OVPn4JjGCIzFzJ7Fjg80O7d93faYiQK+AEz6tXR8RwHmQFUADjn9oC1LwKWUee41dmdK9+kFfqlbnFF9Zkk261S33r+x9szKrYjxWIXQWLdEkYojqKZ+4ZcxjIik0gTrYOgc35v4PggVJK8crtLsp1V5YzAv/LCvmR24dH4Codt9HsYDwAieHj97cUfoyQlTe0KT62/wWXBBJvXe5bDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4Lc4hplX5RdJVLekZnssa5FS5JYpAMp9U0MgSWY2R4=; b=Xri4t8FANxfbIwmt5f2BUnmxCEp5kgjRUy4bBj4XFeP010R8aaP9ODjPLw+aQE3OL8raX+93z6yJJKVEWcGG3XGBGZu7CXAyEvh6RlRGtTHylmZ+8mrtdhB7VBvrEjXpgu52R7ykClNFMlngXHenSJYcjVJmqHWfVULbweCRpi4= Received: from MWHPR15MB1165.namprd15.prod.outlook.com (10.175.3.22) by MWHPR15MB1774.namprd15.prod.outlook.com (10.174.255.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 1 Nov 2019 21:48:54 +0000 Received: from MWHPR15MB1165.namprd15.prod.outlook.com ([fe80::fdc8:5546:bace:15f5]) by MWHPR15MB1165.namprd15.prod.outlook.com ([fe80::fdc8:5546:bace:15f5%5]) with mapi id 15.20.2408.024; Fri, 1 Nov 2019 21:48:47 +0000 From: Song Liu To: Johannes Weiner CC: Andrew Morton , Linux MM , Kernel Team , "Kirill A . Shutemov" , Hugh Dickins , "William Kucharski" , Matthew Wilcox Subject: Re: [PATCH] mm/thp: flush file for !is_shmem PageDirty() case in collapse_file() Thread-Topic: [PATCH] mm/thp: flush file for !is_shmem PageDirty() case in collapse_file() Thread-Index: AQHVj12wRWDZ2/wcSkePDdk389uWy6dz/KCAgAKp1YCAADcVAA== Date: Fri, 1 Nov 2019 21:48:47 +0000 Message-ID: <504DF93A-A225-4DFC-803D-00A9E64BEF48@fb.com> References: <20191030200736.3455046-1-songliubraving@fb.com> <20191030185115.ad780e74c66b6286789559fd@linux-foundation.org> <20191101183137.GA16977@cmpxchg.org> In-Reply-To: <20191101183137.GA16977@cmpxchg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3601.0.10) x-originating-ip: [2620:10d:c090:200::2:364f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0078d600-b973-4ce0-eb33-08d75f154654 x-ms-traffictypediagnostic: MWHPR15MB1774: x-ms-exchange-purlcount: 5 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(376002)(39860400002)(366004)(136003)(346002)(189003)(199004)(66476007)(6246003)(316002)(25786009)(4326008)(76176011)(14454004)(6916009)(30864003)(81166006)(81156014)(86362001)(99286004)(33656002)(186003)(46003)(7736002)(53546011)(5660300002)(102836004)(8936002)(6116002)(8676002)(66946007)(6506007)(305945005)(76116006)(2906002)(6436002)(486006)(966005)(229853002)(54906003)(478600001)(36756003)(66556008)(446003)(66446008)(11346002)(6306002)(256004)(6486002)(2616005)(14444005)(64756008)(6512007)(50226002)(476003)(71200400001)(71190400001);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR15MB1774;H:MWHPR15MB1165.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R4mfgfvqFXe1ICz/eq0D7rODwd1dTCiOtMps9d4Dl6m4XH+QffXCAkwiqnmA9eAMh0z2dgQ6Xn0KWYfgpjgzwo3/ymeiEDa4Nhi5tWaNVm4cvYqqntCGL2URlpFP6Y/XNV7YDVjPiLXnRdDZP57fkAjoXGkaQcbr0YadLkt4iOg7j49blMpOEkUlXY4/SY3KoOvRy3Z0DXee90vmkTJo1MCEnRzL8smvSnWk8r4MHdvqcsT+hRtriNSMQmTvLUSXuKXaRwU+GPdZtNTlTMe34Ko0QFgSKNymSqVljLXZPHPJI2g9mjX4c5Ql/Esi5/fq9G3z2/Lhu/oYmFmZhf0ROKBq21Gxj9ixUp3uIHLxFVLutXqGTIZbNxAlgVGrBHf8xZlCcp3MTV8om4ZZj2pBwpTpFViTIJ0+YLb3LUsw8XH4vAsKIRksq9krLptWuw+/x1Kaey7RI3MT2DjayH8u/MC+apx7F1qtT44lw6+Pklg= Content-Type: text/plain; charset="us-ascii" Content-ID: <7DE5A5733C600744ABBD6A0F17E1838C@namprd15.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0078d600-b973-4ce0-eb33-08d75f154654 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 21:48:47.2398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: luei1CngxTv2TTwd00HZ651cIbnvI1nEKzSP9g0Ce9VduJV+LUDgGitITx0OjATZVtPmDNAhfnDxJALHCiccpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1774 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-01_08:2019-11-01,2019-11-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 malwarescore=0 adultscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911010200 X-FB-Internal: deliver 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: Thanks Johannes! > On Nov 1, 2019, at 11:31 AM, Johannes Weiner wrote: >=20 > On Wed, Oct 30, 2019 at 06:51:15PM -0700, Andrew Morton wrote: >> To that end, here's the combination of >> mmthp-recheck-each-page-before-collapsing-file-thp.patch and this >> patch: >>=20 >> From: Song Liu >> Subject: mm,thp: recheck each page before collapsing file THP >>=20 >> In collapse_file(), for !is_shmem case, current check cannot guarantee >> the locked page is up-to-date. Specifically, xas_unlock_irq() should >> not be called before lock_page() and get_page(); and it is necessary to >> recheck PageUptodate() after locking the page. =20 >>=20 >> With this bug and CONFIG_READ_ONLY_THP_FOR_FS=3Dy, madvise(HUGE)'ed .tex= t >> may contain corrupted data. This is because khugepaged mistakenly >> collapses some not up-to-date sub pages into a huge page, and assumes >> the huge page is up-to-date. This will NOT corrupt data in the disk, >> because the page is read-only and never written back. Fix this by >> properly checking PageUptodate() after locking the page. This check >> replaces "VM_BUG_ON_PAGE(!PageUptodate(page), page);". =20 >>=20 >> Also, move PageDirty() check after locking the page. Current >> khugepaged should not try to collapse dirty file THP, because it is >> limited to read-only .text. Add a warning with the PageDirty() check >> as it should not happen. This warning is added after page_mapping() >> check, because if the page is truncated, it might be dirty. >>=20 >> [songliubraving@fb.com: flush file for !is_shmem PageDirty() case in col= lapse_file()] >> Link: http://lkml.kernel.org/r/20191030200736.3455046-1-songliubraving@= fb.com >> [songliubraving@fb.com: v4] >> Link: http://lkml.kernel.org/r/20191022191006.411277-1-songliubraving@f= b.com >> [songliubraving@fb.com: fix deadlock in collapse_file()] >> Link: http://lkml.kernel.org/r/20191028221414.3685035-1-songliubraving@= fb.com >> Link: http://lkml.kernel.org/r/20191018180345.4188310-1-songliubraving@f= b.com >> Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) = FS") >> Signed-off-by: Song Liu >> Acked-by: Johannes Weiner >> Cc: Kirill A. Shutemov >> Cc: Hugh Dickins >> Cc: William Kucharski >> Signed-off-by: Andrew Morton >> --- >>=20 >> mm/khugepaged.c | 49 +++++++++++++++++++++++++++++++++++++--------- >> 1 file changed, 40 insertions(+), 9 deletions(-) >>=20 >> --- a/mm/khugepaged.c~mmthp-recheck-each-page-before-collapsing-file-thp >> +++ a/mm/khugepaged.c >> @@ -1601,17 +1601,33 @@ static void collapse_file(struct mm_stru >> result =3D SCAN_FAIL; >> goto xa_unlocked; >> } >> - } else if (!PageUptodate(page)) { >> - xas_unlock_irq(&xas); >> - wait_on_page_locked(page); >> - if (!trylock_page(page)) { >> - result =3D SCAN_PAGE_LOCK; >> - goto xa_unlocked; >> + if (WARN_ON_ONCE(PageDirty(page))) { >> + /* >> + * page from readahead should not >> + * be dirty. Show warning if this >> + * somehow happens. >> + */ >> + result =3D SCAN_FAIL; >> + goto out_unlock; >=20 > I'm not sure we need this check here. We have a dirty check on the > locked page below, and it's not clear why there is a suspicion of > readahead producing dirty pages...? I was thinking whether we can remove the=20 if (!is_shmem && PageDirty(page)) { xxxx } check after this. But I agree we can keep it.=20 >=20 >> } >> - get_page(page); >> } else if (PageDirty(page)) { >> + /* >> + * khugepaged only works on read-only fd, >> + * so this page is dirty because it hasn't >> + * been flushed since first write. There >> + * won't be new dirty pages. >> + * >> + * Trigger async flush here and hope the >> + * writeback is done when khugepaged >> + * revisits this page. >> + * >> + * This is a one-off situation. We are not >> + * forcing writeback in loop. >> + */ >> + xas_unlock_irq(&xas); >> + filemap_flush(mapping); >> result =3D SCAN_FAIL; >> - goto xa_locked; >> + goto xa_unlocked; >=20 > We should do this to improve the file THP success rate. But we > shouldn't conflate it with the data corruption bug fixed in the hunks > below: >=20 >> } else if (trylock_page(page)) { >> get_page(page); >> xas_unlock_irq(&xas); >> @@ -1626,7 +1642,12 @@ static void collapse_file(struct mm_stru >> * without racing with truncate. >> */ >> VM_BUG_ON_PAGE(!PageLocked(page), page); >> - VM_BUG_ON_PAGE(!PageUptodate(page), page); >> + >> + /* double check the page is up to date */ >> + if (unlikely(!PageUptodate(page))) { >> + result =3D SCAN_FAIL; >> + goto out_unlock; >> + } >=20 > This... >=20 >> @@ -1642,6 +1663,16 @@ static void collapse_file(struct mm_stru >> goto out_unlock; >> } >>=20 >> + if (!is_shmem && PageDirty(page)) { >> + /* >> + * khugepaged only works on read-only fd, so this >> + * page is dirty because it hasn't been flushed >> + * since first write. >> + */ >> + result =3D SCAN_FAIL; >> + goto out_unlock; >> + } >=20 > ...and this are pretty urgent chunks because they protect the > integrity of the page cache. They should go in asap. >=20 > So I suggest we do two patches instead: Here are the two patches: >=20 > 1. These two locked page checks to fix the corruption in 5.4 >From 6836c7c91396c7b661b2447609ec236badba62b0 Mon Sep 17 00:00:00 2001 From: Song Liu Date: Wed, 23 Oct 2019 11:24:28 +1100 Subject: [PATCH 1/2] mm,thp: recheck each page before collapsing file THP In collapse_file(), for !is_shmem case, current check cannot guarantee the locked page is up-to-date. Specifically, xas_unlock_irq() should not be called before lock_page() and get_page(); and it is necessary to recheck PageUptodate() after locking the page. With this bug and CONFIG_READ_ONLY_THP_FOR_FS=3Dy, madvise(HUGE)'ed .text may contain corrupted data. This is because khugepaged mistakenly collapses some not up-to-date sub pages into a huge page, and assumes the huge page is up-to-date. This will NOT corrupt data in the disk, because the page is read-only and never written back. Fix this by properly checking PageUptodate() after locking the page. This check replaces "VM_BUG_ON_PAGE(!PageUptodate(page), page);". Also, move PageDirty() check after locking the page. Current khugepaged should not try to collapse dirty file THP, because it is limited to read-only .text. The only case we hit a dirty page here is when the page hasn't been written since write. Bail out and retry when this happens. syzbot reported bug on previous version of this patch. [songliubraving@fb.com: v4] Link: http://lkml.kernel.org/r/20191022191006.411277-1-songliubraving@fb.c= om [songliubraving@fb.com: fix deadlock in collapse_file()] Link: http://lkml.kernel.org/r/20191028221414.3685035-1-songliubraving@fb.= com Link: http://lkml.kernel.org/r/20191018180345.4188310-1-songliubraving@fb.c= om [songliubraving@fb.com: flush file for !is_shmem PageDirty() case in collap= se_file()] https://lkml.kernel.org/linux-mm/20191030200736.3455046-1-songliubraving@fb= .com/ Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS"= ) Reported-by: syzbot+efb9e48b9fbdc49bb34a@syzkaller.appspotmail.com Cc: Johannes Weiner Cc: Kirill A. Shutemov Cc: Hugh Dickins Cc: William Kucharski Cc: Andrew Morton Signed-off-by: Song Liu --- mm/khugepaged.c | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 0a1b4b484ac5..40215795d641 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -1601,17 +1601,6 @@ static void collapse_file(struct mm_struct *mm, result =3D SCAN_FAIL; goto xa_unlocked; } - } else if (!PageUptodate(page)) { - xas_unlock_irq(&xas); - wait_on_page_locked(page); - if (!trylock_page(page)) { - result =3D SCAN_PAGE_LOCK; - goto xa_unlocked; - } - get_page(page); - } else if (PageDirty(page)) { - result =3D SCAN_FAIL; - goto xa_locked; } else if (trylock_page(page)) { get_page(page); xas_unlock_irq(&xas); @@ -1626,7 +1615,12 @@ static void collapse_file(struct mm_struct *mm, * without racing with truncate. */ VM_BUG_ON_PAGE(!PageLocked(page), page); - VM_BUG_ON_PAGE(!PageUptodate(page), page); + + /* make sure the page is up to date */ + if (unlikely(!PageUptodate(page))) { + result =3D SCAN_FAIL; + goto out_unlock; + } /* * If file was truncated then extended, or hole-punched, be= fore @@ -1642,6 +1636,16 @@ static void collapse_file(struct mm_struct *mm, goto out_unlock; } + if (!is_shmem && PageDirty(page)) { + /* + * khugepaged only works on read-only fd, so this + * page is dirty because it hasn't been flushed + * since first write. + */ + result =3D SCAN_FAIL; + goto out_unlock; + } + if (isolate_lru_page(page)) { result =3D SCAN_DEL_PAGE_LRU; goto out_unlock; -- 2.17.1 > 2. The filemap_flush() bit to improve THP coverage in 5.5 >From 70092bc81f255314c1d3b1ebb7718ae2be569495 Mon Sep 17 00:00:00 2001 From: Song Liu Date: Tue, 29 Oct 2019 10:08:48 -0700 Subject: [PATCH 2/2] mm/thp: flush file for !is_shmem PageDirty() case in collapse_file() For non-shmem file THPs, khugepaged only collapses read only .text mapping (VM_DENYWRITE). These pages should not be dirty except the case where the file hasn't been flushed since first write. Call filemap_flush() in collapse_file() to accelerate the write back in such cases. [songliubraving@fb.com: flush file for !is_shmem PageDirty() case in collap= se_file()] https://lkml.kernel.org/linux-mm/20191030200736.3455046-1-songliubraving@fb= .com/ Cc: Kirill A. Shutemov Cc: Hugh Dickins Cc: William Kucharski Cc: Johannes Weiner Cc: Andrew Morton Cc: Matthew Wilcox Signed-off-by: Song Liu --- mm/khugepaged.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 40215795d641..513cce897794 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -1601,6 +1601,24 @@ static void collapse_file(struct mm_struct *mm, result =3D SCAN_FAIL; goto xa_unlocked; } + } else if (PageDirty(page)) { + /* + * khugepaged only works on read-only fd, + * so this page is dirty because it hasn't + * been flushed since first write. There + * won't be new dirty pages. + * + * Trigger async flush here and hope the + * writeback is done when khugepaged + * revisits this page. + * + * This is a one-off situation. We are not + * forcing writeback in loop. + */ + xas_unlock_irq(&xas); + filemap_flush(mapping); + result =3D SCAN_FAIL; + goto xa_unlocked; } else if (trylock_page(page)) { get_page(page); xas_unlock_irq(&xas); -- 2.17.1