Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp655758ybe; Wed, 4 Sep 2019 05:55:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqx9PkuRIEIX0eTR2xtVrCDVhUmQhpTna4RrPKnOmlX46Sfy0ML2WF9OHiXZxpCqd9+/feJx X-Received: by 2002:a63:c013:: with SMTP id h19mr16149124pgg.108.1567601701497; Wed, 04 Sep 2019 05:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567601701; cv=none; d=google.com; s=arc-20160816; b=S7/ia76ZwmyctxmE67lDyjOQECNO5GEfMLS27TKVTyTesZ9qRCRbfjCx1sUYxwm7Nv Q58lxF3wCCGPKSq4+rH4Y6+n+qWReDunc73cbm0HdoOQTcMUSAv41In8nyMom+ZIEX74 kQHWiwkJsjc8imazfpXtkuET07kOVNmuSPyzi25ocKD62PBqd31ekj8X3BY7tk04cS9E Qfg39KVTMC3CULxei/dON5E1w6lp/DXZt4U2VyIOucZUkR1B1mVH9r1EnC1VLrUtrNut MqD5vG/PR81SxccGdieISbLL7Oaezi9N81pEjQaWfwulSr9/XKWm73LiLvUCLHdaD2sP KIPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/PGKr5hJIduMjU0siIUG8Q/35EnNxNnQYWKLZEj9Gdk=; b=VYXkMUHf4SIkX0iUy9/hgIQqDJGo0gYfuL+G1crUrr/iCKOv8mZPIx2x/8TXd476a1 07jXjoS/7iktAXI6VUeMRKG4s0gJQojKmRLldtCc7/itWAlsrZdj1Sv3cSOciE6vOqPs eSTE7tkerm4jb354KMbgFUQSPMyWn/k9k81Y8on5puHgnpBMVBOFWVge0QefkBdAXYF8 LfvRonJ/QsEx3sEyM8f6JP5j7KcXkpbLoKZLuTmBNxJ3b3Q/11o6ETeoKTAoW22a8kQV 2NWOuUohn60Y5+37MiNOvaxJWpA8Oc1bzpxTy8ZYxrM9sjwiEsXy1XmFfwzdoAKz9Pja Vzuw== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d23si16783951pls.261.2019.09.04.05.54.44; Wed, 04 Sep 2019 05:55:01 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730070AbfIDMw2 (ORCPT + 99 others); Wed, 4 Sep 2019 08:52:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:49034 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727083AbfIDMw2 (ORCPT ); Wed, 4 Sep 2019 08:52:28 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1084EAF47; Wed, 4 Sep 2019 12:52:27 +0000 (UTC) Date: Wed, 4 Sep 2019 14:52:26 +0200 From: Michal Hocko To: sunqiuyang 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 Message-ID: <20190904125226.GV3838@dhcp22.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157FC541501A9C4C862B2F16FFE316DC190C3402@dggeml512-mbx.china.huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 04-09-19 12:19:11, sunqiuyang wrote: > > Do not top post please > > > > On Wed 04-09-19 07:27:25, sunqiuyang wrote: > > > isolate_migratepages_block() from another thread may try to isolate the page again: > > > > > > for (; low_pfn < end_pfn; low_pfn++) { > > > /* ... */ > > > page = pfn_to_page(low_pfn); > > > /* ... */ > > > if (!PageLRU(page)) { > > > if (unlikely(__PageMovable(page)) && !PageIsolated(page)) { > > > /* ... */ > > > if (!isolate_movable_page(page, isolate_mode)) > > > goto isolate_success; > > > /*... */ > > > isolate_success: > > > list_add(&page->lru, &cc->migratepages); > > > > > > And this page will be added to another list. > > > Or, do you see any reason that the page cannot go through this path? > > > > The page shouldn't be __PageMovable after the migration is done. All the > > state should have been transfered to the new page IIUC. > > > > I don't see where page->mapping is modified after the migration is done. > > Actually, the last comment in move_to_new_page() says, > "Anonymous and movable page->mapping will be cleard by > free_pages_prepare so don't reset it here for keeping > the type to work PageAnon, for example. " > > Or did I miss something? Thanks, This talks about mapping rather than flags stored in the mapping. I can see that in tree migration handlers (z3fold_page_migrate, vmballoon_migratepage via balloon_page_delete, zs_page_migrate via reset_page) all reset the movable flag. I am not sure whether that is a documented requirement or just a coincidence. Maybe it should be documented. I would like to hear from Minchan. -- Michal Hocko SUSE Labs