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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 5BCBEC3A59E for ; Thu, 5 Sep 2019 01:44:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2E7320882 for ; Thu, 5 Sep 2019 01:44:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2E7320882 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 411ED6B0003; Wed, 4 Sep 2019 21:44:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C1C36B0005; Wed, 4 Sep 2019 21:44:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D7E06B0006; Wed, 4 Sep 2019 21:44:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id 0C57C6B0003 for ; Wed, 4 Sep 2019 21:44:20 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id ABAF455F9C for ; Thu, 5 Sep 2019 01:44:19 +0000 (UTC) X-FDA: 75899171838.30.frogs45_7cf4d4d82fc00 X-HE-Tag: frogs45_7cf4d4d82fc00 X-Filterd-Recvd-Size: 4477 Received: from huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Sep 2019 01:44:18 +0000 (UTC) Received: from DGGEML404-HUB.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id 95D609393C3ACEC10E7F; Thu, 5 Sep 2019 09:44:15 +0800 (CST) Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.60]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0439.000; Thu, 5 Sep 2019 09:44:13 +0800 From: sunqiuyang To: Michal Hocko CC: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Subject: RE: [PATCH 1/1] mm/migrate: fix list corruption in migration of non-LRU movable pages Thread-Topic: [PATCH 1/1] mm/migrate: fix list corruption in migration of non-LRU movable pages Thread-Index: AQHVYi7CKRiSaGuZ20KJAhdeZXNZ4qcZaW+AgAFf/lT//8LbAIAAjGWd//+OTACAAMgqDv//hZcAACt21AY= Date: Thu, 5 Sep 2019 01:44:12 +0000 Message-ID: <157FC541501A9C4C862B2F16FFE316DC190C5990@dggeml512-mbx.china.huawei.com> References: <20190903082746.20736-1-sunqiuyang@huawei.com> <20190903131737.GB18939@dhcp22.suse.cz> <157FC541501A9C4C862B2F16FFE316DC190C1B09@dggeml512-mbx.china.huawei.com> <20190904063836.GD3838@dhcp22.suse.cz> <157FC541501A9C4C862B2F16FFE316DC190C2EBD@dggeml512-mbx.china.huawei.com> <20190904081408.GF3838@dhcp22.suse.cz> <157FC541501A9C4C862B2F16FFE316DC190C3402@dggeml512-mbx.china.huawei.com>,<20190904125226.GV3838@dhcp22.suse.cz> In-Reply-To: <20190904125226.GV3838@dhcp22.suse.cz> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.249.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: =0A= ________________________________________=0A= From: Michal Hocko [mhocko@kernel.org]=0A= Sent: Wednesday, September 04, 2019 20:52=0A= To: sunqiuyang=0A= Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org=0A= Subject: Re: [PATCH 1/1] mm/migrate: fix list corruption in migration of no= n-LRU movable pages=0A= =0A= On Wed 04-09-19 12:19:11, sunqiuyang wrote:=0A= > > Do not top post please=0A= > >=0A= > > On Wed 04-09-19 07:27:25, sunqiuyang wrote:=0A= > > > isolate_migratepages_block() from another thread may try to isolate t= he page again:=0A= > > >=0A= > > > for (; low_pfn < end_pfn; low_pfn++) {=0A= > > > /* ... */=0A= > > > page =3D pfn_to_page(low_pfn);=0A= > > > /* ... */=0A= > > > if (!PageLRU(page)) {=0A= > > > if (unlikely(__PageMovable(page)) && !PageIsolated(page)) {=0A= > > > /* ... */=0A= > > > if (!isolate_movable_page(page, isolate_mode))=0A= > > > goto isolate_success;=0A= > > > /*... */=0A= > > > isolate_success:=0A= > > > list_add(&page->lru, &cc->migratepages);=0A= > > >=0A= > > > And this page will be added to another list.=0A= > > > Or, do you see any reason that the page cannot go through this path?= =0A= > >=0A= > > The page shouldn't be __PageMovable after the migration is done. All th= e=0A= > > state should have been transfered to the new page IIUC.=0A= > >=0A= >=0A= > I don't see where page->mapping is modified after the migration is done.= =0A= >=0A= > Actually, the last comment in move_to_new_page() says,=0A= > "Anonymous and movable page->mapping will be cleard by=0A= > free_pages_prepare so don't reset it here for keeping=0A= > the type to work PageAnon, for example. "=0A= >=0A= > Or did I miss something? Thanks,=0A= =0A= This talks about mapping rather than flags stored in the mapping.=0A= I can see that in tree migration handlers (z3fold_page_migrate,=0A= vmballoon_migratepage via balloon_page_delete, zs_page_migrate via=0A= reset_page) all reset the movable flag. I am not sure whether that is a=0A= documented requirement or just a coincidence. Maybe it should be=0A= documented. I would like to hear from Minchan.=0A= =0A= ---=0A= I checked the three migration handlers and only found __ClearPageMovable,= =0A= which clears registered address_space val with keeping PAGE_MAPPING_MOVABLE= flag,=0A= so the page should still be __PageMovable when caught by another migration = thread. Right?=0A= =0A= ---=0A= =0A= --=0A= Michal Hocko=0A= SUSE Labs=0A=