Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3105662pxj; Mon, 7 Jun 2021 02:21:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaHUaylbFUXdVKUkDQuk9xaiLiYGsB8Wnv7bPO+3Bk4cmFtZJy9BjvGZnQegtgbmyaJSH3 X-Received: by 2002:aa7:d7cf:: with SMTP id e15mr19475948eds.114.1623057707781; Mon, 07 Jun 2021 02:21:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623057707; cv=none; d=google.com; s=arc-20160816; b=GiKXzWF8CpDN+MKzU6PzMttRVnBFvrHdJlUzbeE4qBcuwu6Zm5DI9G8Hl0tuR5M10L DjPQmy2+NXJRgg9AMU+BnQAfNDipMayCzHBcwkO8S1aAqpqcWnpNh6uPMPxIRRcRvLQy +hFS4lfST2HMZP0XrCRsKEKpdyH2CY5BzOISFSOsGfGmJGvUaVWgjccR+RPMhKRH8j4H YAnatkRe/vHFWurGgc8THVOJuigLmggSizwbZl9xDsBBEIxmfwaafM9g36AOgUgDVoBh n0s28LdIWvlx2KV346i74snc117wjX1w6gdkTX1gREJUVTy8Zy5Q89PCnpZMwU/nt+g0 lcpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=7xcuW3h+QNmarUOLdTIUMS3UvSBWzFxW9yikOSwTBXA=; b=kLy6Brw+JIR1aWp7U3sBARlKYhdJFJ8S6GnbeXI/GFPzdLoArEsySvMHmVDBBxWDbH d87XOEdWXMVoHMKCYzIFfDRDqPpXd157V+BE0ws6R4U5TkCB+w6HZqOTHUKb+cbSkGS5 UL7FH4/sGCm0tydZGgFkKWXrKjN7JOXQecf5OUey3n/z5L7Ljm2EzfPrB2LHqXxE5PF9 lKaLX4tW3u4wJyE38RLZm/oMF+qBZe0LH6rHaBy9h8qeo2xm0BB+hCFvGSWPaVhpti2Y 6iuPOvsKVj59LSgPwl8R+3+ha6wESUvPMYIuU0qEHstYJENIkr5ejiJfae6gWZ7quRvA OmMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h23si11381636edq.536.2021.06.07.02.21.25; Mon, 07 Jun 2021 02:21:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230222AbhFGJVz (ORCPT + 99 others); Mon, 7 Jun 2021 05:21:55 -0400 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:46494 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229966AbhFGJVz (ORCPT ); Mon, 7 Jun 2021 05:21:55 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=yaohuiwang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0UbaGHXf_1623057601; Received: from localhost(mailfrom:yaohuiwang@linux.alibaba.com fp:SMTPD_---0UbaGHXf_1623057601) by smtp.aliyun-inc.com(127.0.0.1); Mon, 07 Jun 2021 17:20:01 +0800 From: Yaohui Wang To: dave.hansen@linux.intel.com Cc: luto@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, yaohuiwang@linux.alibaba-inc.com, luoben@linux.alibaba.com, Yahui Wang Subject: [PATCH] mm: fix pfn calculation mistake in __ioremap_check_ram Date: Mon, 7 Jun 2021 17:19:39 +0800 Message-Id: <20210607091938.47960-1-yaohuiwang@linux.alibaba.com> X-Mailer: git-send-email 2.24.3 (Apple Git-128) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org According to the source code in function arch/x86/mm/ioremap.c:__ioremap_caller, after __ioremap_check_mem, if the mem range is IORES_MAP_SYSTEM_RAM, then __ioremap_caller should fail. But because of the pfn calculation problem, __ioremap_caller can success on IORES_MAP_SYSTEM_RAM region when the @size parameter is less than PAGE_SIZE. This may cause misuse of the ioremap function and raise the risk of performance issues. For example, ioremap(phys, PAGE_SIZE-1) may cause the direct memory mapping of @phys to be uncached, and iounmap won't revert this change. This patch fixes this issue. In arch/x86/mm/ioremap.c:__ioremap_check_ram, start_pfn should wrap down the res->start address, and end_pfn should wrap up the res->end address. This makes the check more strict and should be more reasonable. Signed-off-by: Ben Luo Signed-off-by: Yahui Wang --- arch/x86/mm/ioremap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 9e5ccc56f..79adf0d2d 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -74,8 +74,8 @@ static unsigned int __ioremap_check_ram(struct resource *res) if ((res->flags & IORESOURCE_SYSTEM_RAM) != IORESOURCE_SYSTEM_RAM) return 0; - start_pfn = (res->start + PAGE_SIZE - 1) >> PAGE_SHIFT; - stop_pfn = (res->end + 1) >> PAGE_SHIFT; + start_pfn = res->start >> PAGE_SHIFT; + stop_pfn = (res->end + PAGE_SIZE) >> PAGE_SHIFT; if (stop_pfn > start_pfn) { for (i = 0; i < (stop_pfn - start_pfn); ++i) if (pfn_valid(start_pfn + i) && -- 2.25.1