From patchwork Mon Feb 1 14:56:25 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 60933 Delivered-To: patch@linaro.org Received: by 10.112.130.2 with SMTP id oa2csp56418lbb; Mon, 1 Feb 2016 06:57:42 -0800 (PST) X-Received: by 10.98.7.14 with SMTP id b14mr13443503pfd.40.1454338662571; Mon, 01 Feb 2016 06:57:42 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id m23si14816234pfi.250.2016.02.01.06.57.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Feb 2016 06:57:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org 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 1aQFuP-0007wy-A2; Mon, 01 Feb 2016 14:56:53 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aQFuL-0007jl-8p for linux-arm-kernel@lists.infradead.org; Mon, 01 Feb 2016 14:56:49 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5E21B3A1; Mon, 1 Feb 2016 06:55:45 -0800 (PST) Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E4A0E3F21A; Mon, 1 Feb 2016 06:56:27 -0800 (PST) Date: Mon, 1 Feb 2016 14:56:25 +0000 From: Catalin Marinas To: Mark Rutland Subject: Re: [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings Message-ID: <20160201145624.GF15514@e104818-lin.cambridge.arm.com> References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org> <1454324093-15998-3-git-send-email-ard.biesheuvel@linaro.org> <20160201141004.GI674@leverpostej> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160201141004.GI674@leverpostej> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160201_065649_379999_FF8FE096 X-CRM114-Status: GOOD ( 14.97 ) X-Spam-Score: -7.4 (-------) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-7.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: marc.zyngier@arm.com, will.deacon@arm.com, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org On Mon, Feb 01, 2016 at 02:10:04PM +0000, Mark Rutland wrote: > On Mon, Feb 01, 2016 at 11:54:47AM +0100, Ard Biesheuvel wrote: > > This wires up the existing generic huge-vmap feature, which allows > > ioremap() to use PMD or PUD sized block mappings. It also adds support > > to the unmap path for dealing with block mappings, which will allow us > > to unmap the __init region using unmap_kernel_range() in a subsequent > > patch. > > > > Signed-off-by: Ard Biesheuvel > > Reviewed-by: Mark Rutland > > I was a little bit worried about this potentially not matching the > granularity we used when creating mappings, but seeing how > p?d_clear_huge are called by unmap_kernel_range, I think this is fine. I tried the warnings below and they didn't trigger. Anyway, if we ever unmapped more, I guess we would have quickly triggered a kernel fault. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel diff --git a/mm/vmalloc.c b/mm/vmalloc.c index fb42a5bffe47..40362d62d1e1 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -77,8 +77,10 @@ static void vunmap_pmd_range(pud_t *pud, unsigned long addr, unsigned long end) pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); - if (pmd_clear_huge(pmd)) + if (pmd_clear_huge(pmd)) { + WARN_ON(next < addr + PMD_SIZE); continue; + } if (pmd_none_or_clear_bad(pmd)) continue; vunmap_pte_range(pmd, addr, next); @@ -93,8 +95,10 @@ static void vunmap_pud_range(pgd_t *pgd, unsigned long addr, unsigned long end) pud = pud_offset(pgd, addr); do { next = pud_addr_end(addr, end); - if (pud_clear_huge(pud)) + if (pud_clear_huge(pud)) { + WARN_ON(next < addr + PUD_SIZE); continue; + } if (pud_none_or_clear_bad(pud)) continue; vunmap_pmd_range(pud, addr, next);