From patchwork Sun Nov 1 20:24:25 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 7532691 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 6272EBEEA4 for ; Sun, 1 Nov 2015 20:27:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7C39720667 for ; Sun, 1 Nov 2015 20:27:20 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 81A68205DD for ; Sun, 1 Nov 2015 20:27:19 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZszBL-0004Sh-SL; Sun, 01 Nov 2015 20:24:51 +0000 Received: from mga03.intel.com ([134.134.136.65]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZszBI-0003p6-Oy for linux-arm-kernel@lists.infradead.org; Sun, 01 Nov 2015 20:24:49 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 01 Nov 2015 12:24:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,230,1444719600"; d="scan'208";a="824424188" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga001.fm.intel.com with ESMTP; 01 Nov 2015 12:24:27 -0800 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 1 Nov 2015 12:24:26 -0800 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.53]) by ORSMSX156.amr.corp.intel.com ([169.254.8.249]) with mapi id 14.03.0248.002; Sun, 1 Nov 2015 12:24:26 -0800 From: "Williams, Dan J" To: "torvalds@linux-foundation.org" , "akpm@linux-foundation.org" Subject: [GIT PULL] memremap fix for 4.3 (v2) Thread-Topic: [GIT PULL] memremap fix for 4.3 (v2) Thread-Index: AQHRFONNRWtqL2AtaUmV31xG1RIyfQ== Date: Sun, 1 Nov 2015 20:24:25 +0000 Message-ID: <1446409463.10982.4.camel@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-ID: <00E6B5BE9D992144A11417B10768B4C2@intel.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151101_122448_881075_52FCF652 X-CRM114-Status: GOOD ( 20.17 ) X-Spam-Score: -6.9 (------) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "rmk+kernel@arm.linux.org.uk" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "ard.biesheuvel@linaro.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Linus, please pull from... git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a reworked version of the memremap highmem fix. The change since v1 is dropping the kmap fallback. --- The new memremap() api introduced in the 4.3 cycle to unify/replace ioremap_cache() and ioremap_wt() is mishandling the highmem case. This patch has received a build success notification from a 0day-kbuild-robot run and has received an ack from Ard. The following changes since commit 25cb62b76430a91cc6195f902e61c2cb84ade622: Linux 4.3-rc5 (2015-10-11 11:09:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes for you to fetch changes up to 182475b7a2831abf7e6ca83b2aced0bef5dcdfd3: memremap: fix highmem support (2015-10-26 16:55:56 -0400) ---------------------------------------------------------------- Dan Williams (1): memremap: fix highmem support kernel/memremap.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) commit 182475b7a2831abf7e6ca83b2aced0bef5dcdfd3 Author: Dan Williams Date: Mon Oct 26 16:55:56 2015 -0400 memremap: fix highmem support Currently memremap checks if the range is "System RAM" and returns the kernel linear address. This is broken for highmem platforms where a range may be "System RAM", but is not part of the kernel linear mapping. Fallback to ioremap_cache() in these cases, to let the arch code attempt to handle it. Note that ARM ioremap will WARN when attempting to remap ram, and in that case the caller needs to be fixed. For this reason, existing ioremap_cache() usages for ARM are already trained to avoid attempts to remap ram. The impact of this bug is low for now since the pmem driver is the only user of memremap(), but this is important to fix before more conversions to memremap arrive in 4.4. Cc: Rafael J. Wysocki Reported-by: Ard Biesheuvel Acked-by: Ard Biesheuvel Signed-off-by: Dan Williams diff --git a/kernel/memremap.c b/kernel/memremap.c index 72b0c66628b6..9d6b55587eaa 100644 --- a/kernel/memremap.c +++ b/kernel/memremap.c @@ -24,6 +24,16 @@ __weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size) } #endif +static void *try_ram_remap(resource_size_t offset, size_t size) +{ + struct page *page = pfn_to_page(offset >> PAGE_SHIFT); + + /* In the simple case just return the existing linear address */ + if (!PageHighMem(page)) + return __va(offset); + return NULL; /* fallback to ioremap_cache */ +} + /** * memremap() - remap an iomem_resource as cacheable memory * @offset: iomem resource start address @@ -66,8 +76,8 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags) * the requested range is potentially in "System RAM" */ if (is_ram == REGION_INTERSECTS) - addr = __va(offset); - else + addr = try_ram_remap(offset, size); + if (!addr) addr = ioremap_cache(offset, size); }