Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp218443ybf; Thu, 27 Feb 2020 19:39:57 -0800 (PST) X-Google-Smtp-Source: APXvYqzYyXu5TyMFMCq/FV9cfpgTX4L0BtMKbjdXbPfIy3jKK4+bQGMlwvCi6SdqltqhWBqWZmhg X-Received: by 2002:aca:abd4:: with SMTP id u203mr1667964oie.104.1582861197827; Thu, 27 Feb 2020 19:39:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582861197; cv=none; d=google.com; s=arc-20160816; b=LTM0Vg09WWlwIeW936H8VQhs98da5oqzUZfL1wyL/6uNSSx3y0fvZ85ctybtACco+4 RTvZuGpCFQ0AvukRWQ4PyyRe72W9KnpR/oOSGXRbZqwIe2xsMZD8tMToP4qyNklqGPTB Ia2hNSb+Ie/U3ehbpokBh0CiVWwYTH8qLPPcBddgmnDpV61jFKjICnxgRYbM3tUg9Gg2 k5Q1SBeBeLqiuHhzqrHKnJJvlNi95kyE8vcs78Og7tCWgLj13WT0TViErs5vxUxRj8Up R9zd6aZ2COsU8D8fHsHEvi5eJWgFXiRpiY8TwqTQVKfsBRYB/1o8qfEKgFOQu7wUuMld yCqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=uK5K8Q/LJiHQAnlLVCojigmsFGLwtR4XApK99/lsuZQ=; b=gkIXHpm0NXVAaHsB2oCkbeL1hxX+hPpnP9n69bsuSSsPOOiaL+NrnX1YqlrJZ2wgjV QcWU2urFTefId3jvIw+XjufZTliHAUCyhjKmdCoWIkzedIA9avWjxH2nhR52i7KZKhvE to4FKZ598vtKhO6XVlDkuf8m4aVHukeypRLBmjpselZFd/YaSlVvkH04/SRhNUDsHaA/ PAHOWlrzdLBf6eHdfjK67BnQFglRRf00tHE5J9WmbUW1OFUNi7zKozJdwQeoU9ujKX/y 9CMezYKPY/opMaKF+D8rNPvY0vn1FsjsL3pZ5kF0IDUH7jHLdwdtJsACildEfbas8sfY TQ/w== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1si857643otf.102.2020.02.27.19.39.46; Thu, 27 Feb 2020 19:39:57 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730824AbgB1Dil (ORCPT + 99 others); Thu, 27 Feb 2020 22:38:41 -0500 Received: from mga09.intel.com ([134.134.136.24]:36522 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730807AbgB1Dik (ORCPT ); Thu, 27 Feb 2020 22:38:40 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2020 19:38:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,493,1574150400"; d="scan'208";a="232107356" Received: from yhuang-dev.sh.intel.com ([10.239.159.23]) by orsmga008.jf.intel.com with ESMTP; 27 Feb 2020 19:38:37 -0800 From: "Huang, Ying" To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Dave Hansen , David Hildenbrand , Mel Gorman , Vlastimil Babka , Zi Yan , Michal Hocko , Minchan Kim , Johannes Weiner , Hugh Dickins Subject: [RFC 1/3] mm, migrate: Check return value of try_to_unmap() Date: Fri, 28 Feb 2020 11:38:17 +0800 Message-Id: <20200228033819.3857058-2-ying.huang@intel.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200228033819.3857058-1-ying.huang@intel.com> References: <20200228033819.3857058-1-ying.huang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Huang Ying During the page migration, try_to_unmap() is called to replace the page table entries with the migration entries. Now its return value is ignored, that is generally OK in most cases. But in theory, it's possible that try_to_unmap() return false (failure) for the page migration after arch_unmap_one() is called in unmap code. Even if without arch_unmap_one(), it makes code more robust for the future code changing to check the return value. Known issue: I don't know what is the appropriate error code for try_to_unmap() failure. Whether EIO is OK? Signed-off-by: "Huang, Ying" Cc: Dave Hansen Cc: David Hildenbrand Cc: Mel Gorman Cc: Vlastimil Babka Cc: Zi Yan Cc: Michal Hocko Cc: Minchan Kim Cc: Johannes Weiner Cc: Hugh Dickins --- mm/migrate.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 3900044cfaa6..981f8374a6ef 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1116,8 +1116,11 @@ static int __unmap_and_move(struct page *page, struct page *newpage, /* Establish migration ptes */ VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma, page); - try_to_unmap(page, - TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS); + if (!try_to_unmap(page, + TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS)) { + rc = -EIO; + goto out_unlock_both; + } page_was_mapped = 1; } @@ -1337,8 +1340,11 @@ static int unmap_and_move_huge_page(new_page_t get_new_page, goto put_anon; if (page_mapped(hpage)) { - try_to_unmap(hpage, - TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS); + if (!try_to_unmap(hpage, + TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS)) { + rc = -EIO; + goto unlock_both; + } page_was_mapped = 1; } @@ -1349,6 +1355,7 @@ static int unmap_and_move_huge_page(new_page_t get_new_page, remove_migration_ptes(hpage, rc == MIGRATEPAGE_SUCCESS ? new_hpage : hpage, false); +unlock_both: unlock_page(new_hpage); put_anon: @@ -2558,8 +2565,7 @@ static void migrate_vma_unmap(struct migrate_vma *migrate) continue; if (page_mapped(page)) { - try_to_unmap(page, flags); - if (page_mapped(page)) + if (!try_to_unmap(page, flags)) goto restore; } -- 2.25.0