Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp994363ybl; Tue, 28 Jan 2020 16:28:31 -0800 (PST) X-Google-Smtp-Source: APXvYqw5aJCp/Qv5lfTNOTkoUIHNPDWkOjLuKwau3E5jvrFcTgEzH51dq30S5ayb08ADpoqqhjPl X-Received: by 2002:a9d:58cb:: with SMTP id s11mr19370893oth.55.1580257711523; Tue, 28 Jan 2020 16:28:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580257711; cv=none; d=google.com; s=arc-20160816; b=b82Vyg3jRVPfL/1Mqnh4yRkAQgygeB7DY7veCerWYafFV84ArpiDNurGfp+PVPONgi W+pxn/ab5OcyGCYu4hpaigg+hRUWX+asaraVvCixEh4Ved8jprTKv0q9tP44KlYzOm39 7PZn9e8MutNtG4KIpskqXsVoeOFn6aAd8yeDbTuoTD5EQ5wQtNYWZniyzuFHEy/oolvS lZtCbCMkrNin8N+GiPsAzZSny5Bc0EczC9f2BL88QH4It0vE7PGXPJ9Vs6KNILvkKe0u fa5UCN3RGF8DqXcX4LLFi8Ag/RaIovaF75Bj+WyXfMIRxIVJh27QQoLhVWbBd4p8U/UY tWww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Khs6rLgOqbS+zy6EcBO2SJBdjzN6Fy3mAi68RQhDS9U=; b=JbQpzhBnkxlb1A12ycb7ABoK9K28OjTbLhkSOAEZ8sQWsLIMhuW9NquxtslaCaQ/nT 5rRb45mWyytZi4ARUrOhYGFOZoqk3sk8JSk8ELX+LIUwrdfemgZDOu96nCrsZfE8j4Lt LtGRhuA0uLBQH0O6vzuULgpj67/WcOGqmYuVCPYcSbNFMiW0bseZokldjM/PtA0HNSF0 +V1aWWyDqfJwjadlWsoA2z11Zv+r0f0dPjMytCPrYVbq4nFJOm2YeAKsH5MwuUuLJmLG SS8fsOZ9MU8h6z+goLBrD39837PJtqnYMVmlc4vW+fKkL/AnH8gjSLSFE0ecwE4D7gH7 d74A== 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 c67si205872oib.276.2020.01.28.16.28.19; Tue, 28 Jan 2020 16:28:31 -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 S1726617AbgA2A1R (ORCPT + 99 others); Tue, 28 Jan 2020 19:27:17 -0500 Received: from mga11.intel.com ([192.55.52.93]:12087 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726565AbgA2A1P (ORCPT ); Tue, 28 Jan 2020 19:27:15 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2020 16:27:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,375,1574150400"; d="scan'208";a="229456104" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga003.jf.intel.com with ESMTP; 28 Jan 2020 16:27:12 -0800 From: Wei Yang To: akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, kirill@shutemov.name, dan.j.williams@intel.com, yang.shi@linux.alibaba.com, thellstrom@vmware.com, richardw.yang@linux.intel.com Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, digetx@gmail.com Subject: [Patch v2 3/4] mm/mremap: calculate extent in one place Date: Wed, 29 Jan 2020 08:26:41 +0800 Message-Id: <20200129002642.13508-4-richardw.yang@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200129002642.13508-1-richardw.yang@linux.intel.com> References: <20200129002642.13508-1-richardw.yang@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Page tables is moved on the base of PMD. This requires both source and destination range should meet the requirement. Current code works well since move_huge_pmd() and move_normal_pmd() would check old_addr and new_addr again. And then return to move_ptes() if the either of them is not aligned. In stead of calculating the extent separately, it is better to calculate in one place, so we know it is not necessary to try move pmd. By doing so, the logic seems a little clear. Signed-off-by: Wei Yang --- mm/mremap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/mremap.c b/mm/mremap.c index c2af8ba4ba43..b2f3344d090a 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -258,6 +258,9 @@ unsigned long move_page_tables(struct vm_area_struct *vma, extent = next - old_addr; if (extent > old_end - old_addr) extent = old_end - old_addr; + next = (new_addr + PMD_SIZE) & PMD_MASK; + if (extent > next - new_addr) + extent = next - new_addr; old_pmd = get_old_pmd(vma->vm_mm, old_addr); if (!old_pmd) continue; @@ -301,9 +304,6 @@ unsigned long move_page_tables(struct vm_area_struct *vma, if (pte_alloc(new_vma->vm_mm, new_pmd)) break; - next = (new_addr + PMD_SIZE) & PMD_MASK; - if (extent > next - new_addr) - extent = next - new_addr; move_ptes(vma, old_pmd, old_addr, old_addr + extent, new_vma, new_pmd, new_addr, need_rmap_locks); } -- 2.17.1