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,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS 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 534A2C10DCE for ; Tue, 24 Mar 2020 04:22:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 125D320724 for ; Tue, 24 Mar 2020 04:22:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ahkk82cU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 125D320724 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95DB96B00C8; Tue, 24 Mar 2020 00:22:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90F006B00C9; Tue, 24 Mar 2020 00:22:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FE226B00CA; Tue, 24 Mar 2020 00:22:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 631486B00C8 for ; Tue, 24 Mar 2020 00:22:04 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7B1B21874090E for ; Tue, 24 Mar 2020 04:22:04 +0000 (UTC) X-FDA: 76628958168.26.boats04_6962774185b52 X-HE-Tag: boats04_6962774185b52 X-Filterd-Recvd-Size: 5850 Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Mar 2020 04:22:04 +0000 (UTC) Received: by mail-il1-f194.google.com with SMTP id m9so15544441ilq.12 for ; Mon, 23 Mar 2020 21:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2CcHH1y2APFEoF0YOhfKpACJNP+3Y67aURt0jhLpXcA=; b=Ahkk82cUdxgWoqPKWLaAuo3dpyUsneQOneC5ZM8QpBnc23DRmjCOje+m1YDQRcyZrw C74WuKRjsgDMqZWN1U33EmW9g12OGeUT2iwtH/pnahf+okraJrltJGnJDNDjCM1H6B20 oO6WuFaOxoT+4h0jlIpCcuzZWPgKW+nUjqb6RJiAIKbPLDhY6m3SzgIBW935qRFdQyUP yUnaXaQdvFSfOoCacgrMPYliv9soJnJXXL0oSJmrSQFEe014RKQTH2W126p8fTRsMSPq H1Kargv2TjyWCFUePToiVivIA1NHG2augJVAZnTVT5S1S4q51+nkfqi3A6HNLSzJkTl4 2AZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2CcHH1y2APFEoF0YOhfKpACJNP+3Y67aURt0jhLpXcA=; b=s5z+43wr/hmLoe0r2vrthXg71Dv+Cf2IKktVNgz9OuXa7lMT7+C45N8bp7N0IK3oEv l9FhmdK8EhptbK2DQJ7ZeLx/lNGRYajo7OADiiPzFe/xnqKHt3i08l+TYEsMpkbqjMfW Jcgt4WXyC1lnL4GC62rFKQ1cYeruoJSH+c3j82dk4iCwxvavpBsPwg/9ur46StcyXImO AevXIMaJDLG1njDz281r9A1Re8J0F2RoAN/PLjuYM/9Ca5Kwk1vlozngjHCXi1/UMx4C ARJJ1aAL8+rYqz9MsxFTTrhw1sQKTxXcLOCsBECJJSFt3CItWa2svkFojWNTx+teGQeE Ucgw== X-Gm-Message-State: ANhLgQ1x0LYvCjHb1Myw8UTwkWILwwH2niYEdzb6rTn0+UdGvSA39rV7 xUWsUWDYUSv9rAbct9m9GoUHtuKe3HHScICv7Q== X-Google-Smtp-Source: ADFU+vsvz0hlXOwVBK/EG+rnUqVskvAvNk2L+3XTfQEtSoY2O+NGhTYAXN4T0fZYZiMZ5U84b0elLWgE5D6JwWrZSL4= X-Received: by 2002:a92:350a:: with SMTP id c10mr8644847ila.12.1585023723039; Mon, 23 Mar 2020 21:22:03 -0700 (PDT) MIME-Version: 1.0 References: <1584885427-4952-1-git-send-email-kernelfans@gmail.com> <20200323073408.GA7524@dhcp22.suse.cz> In-Reply-To: From: Pingfan Liu Date: Tue, 24 Mar 2020 12:21:51 +0800 Message-ID: Subject: Re: [PATCH] mm/rmap: fix the handling of device private page in try_to_unmap_one() To: Ralph Campbell Cc: Michal Hocko , Linux-MM , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , John Hubbard , "Kirill A . Shutemov" , Aneesh Kumar , Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 for your explanation. On Tue, Mar 24, 2020 at 8:20 AM Ralph Campbell wrote= : > > > On 3/23/20 12:34 AM, Michal Hocko wrote: > > On Sun 22-03-20 21:57:07, Pingfan Liu wrote: > >> For zone_device, migration can only happen on is_device_private_page(p= age). > >> Correct the logic in try_to_unmap_one(). > > > > Maybe it is just me lacking knowledge in the zone_device ZOO. But > > this really deserves a much more detailed explanation IMHO. It seems > > a5430dda8a3a ("mm/migrate: support un-addressable ZONE_DEVICE page in > > migration") deliberately made the decision to allow unmapping these > > pages? Is the check just wrong, inncomplete? Why? > > > > What is the real user visible problem here? > > > >> Signed-off-by: Pingfan Liu > >> Cc: J=C3=A9r=C3=B4me Glisse > >> Cc: Michal Hocko > >> Cc: John Hubbard > >> Cc: Kirill A. Shutemov > >> Cc: Aneesh Kumar > >> Cc: Andrew Morton > >> To: linux-mm@kvack.org > >> --- > >> mm/rmap.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/mm/rmap.c b/mm/rmap.c > >> index b838647..ffadf3e 100644 > >> --- a/mm/rmap.c > >> +++ b/mm/rmap.c > >> @@ -1380,7 +1380,7 @@ static bool try_to_unmap_one(struct page *page, = struct vm_area_struct *vma, > >> > >> if (IS_ENABLED(CONFIG_MIGRATION) && (flags & TTU_MIGRATION) && > >> is_zone_device_page(page) && !is_device_private_page(page)) > >> - return true; > >> + return false; > > Pages can be mapped in multiple vmas. Returning false here will only brea= k out > of the loop and skip any other vmas mapping this page which is a minor op= timization > but shouldn't really affect what try_to_unmap_one() does. Yes, it returns false to terminate further iteration. And I think fs-dax page would not go through this path. The unmap of fs-dax should go through: umount fs, and arch_remove_memory(). > > >> if (flags & TTU_SPLIT_HUGE_PMD) { > >> split_huge_pmd_address(vma, address, > >> @@ -1487,7 +1487,7 @@ static bool try_to_unmap_one(struct page *page, = struct vm_area_struct *vma, > >> > >> if (IS_ENABLED(CONFIG_MIGRATION) && > >> (flags & TTU_MIGRATION) && > >> - is_zone_device_page(page)) { > >> + is_device_private_page(page)) { > >> swp_entry_t entry; > >> pte_t swp_pte; > > Since the page was checked for !device private, this is more clear but sh= ouldn't > change anything. Yes. It just makes things clear. Thanks, Pingfan